1

Topic: The correct usage QWaitCondition

Standard situation - two flows porducer and consumer: QMutex mutex; QList <...> dataColl;//Consumer {QMutexLocker locker (&mutex); waitCondition.wait (&mutex); dataColl.pop_front ();}//Producer {QMutexLocker locker (&mutex); dataColl.push (...); waitCondition.wakeOne ();} we Assume, flow Producer supposed in the list the data and caused wakeOne () before flow onsumer passed in a sleeping mode. It turns out that while Producer does not suppose the new data in the list, flow Consumer hangs up in wait (). Judging by implementation wait () there there is a following: 1. mutex-> unlock (); 2. wait (...); 3. mutex-> lock (); And wakeOne () can theoretically happen in an interval between calls 1. And 2. Whether correctly I understand, what the unique reliable decision is to use ?: waitCondition.wait (&mutex, 1000)

2

Re: The correct usage QWaitCondition

Hello, NordSky, you wrote: whether NS> Correctly I understand, what the unique reliable decision is to use ?: No, waitCondition it is object of synchronization of kernel level and operation   and passage to waiting is atomic. No other flows are fulfilled at this time. It is enough to deliver check on, whether there is something in the list before to wait. I did so in the code. Truth I still what for added counters of the expecting... It was probably reinsured that condition can "be cocked" when nobody waits and to remember the "". QMutex mutex; QList <...> dataColl;//Consumer {QMutexLocker locker (&mutex); while (dataColl.isEmpty ()) waitCondition.wait (&mutex); dataColl.pop_front ();}//Producer {QMutexLocker locker (&mutex); dataColl.push (...); waitCondition.wakeOne ();}

3

Re: The correct usage QWaitCondition

Hello, NordSky, you wrote: NS> Judging by implementation wait () there there is a following: 1. mutex-> unlock (); 2. wait (...); 3. mutex-> lock (); NS> And wakeOne () can theoretically happen in an interval between calls 1. And 2.  comes in wait blocked, and it will be unblocked after  is ready to wake up on event, something like 1. register_wake_event (...); 2. mutex-> unlock (); 3. wait_on_wake_event (...);//quits immediately if wake_event it is already ready. 4. mutex-> lock (); the Described problem could exist, if the gaped event could be to an input in waitCondition.wait (&mutex); But from it protects  since it is impossible to place in dataColl without capture .

4

Re: The correct usage QWaitCondition

Hello, Maniacal, you wrote: M> Is not present, waitCondition it is object of synchronization of kernel level and operation   and passage to waiting is atomic. No other flows are fulfilled at this time. It is enough to deliver check on, whether there is something in the list before to wait. I did so in the code. Truth I still what for added counters of the expecting... It was probably reinsured that condition can "be cocked" when nobody waits and to remember the "". Attentively looked at implementation qeaitcondition under win, and, yes - you are right, it is necessary to add simply buffer check on presence in it the data before to wait. Thanks.