- * We can publish the new pointer before we change the current qparity.
- * Readers seeing the new pointer while being in the previous qparity
- * window will make us wait until the end of the quiescent state before
- * we release the unrelated memory area. However, given we hold the
- * urcu_mutex, we are making sure that no further garbage collection can
- * occur until we release the mutex, therefore we guarantee that this
- * given reader will have completed its execution using the new pointer
- * when the next quiescent state window will be over.
+ * Must commit qparity update to memory before waiting for parity
+ * 1 quiescent state. Failure to do so could result in the writer
+ * waiting forever while new readers are always accessing data (no
+ * progress).