Talk:cpp/thread/condition variable


[edit] (Solved) Possible Race Condition in Example Code?

It's possible that the call to cv.notify_one() in worker_thread() happens before cv.wait() in main(). In this case the main thread waits forever. The fix would be to remove lk.unlock() in worker_thread(). Is that correct? Ens (talk) 06:53, 1 October 2014 (PDT)

no, main will not wait forever (or at all) in that case: note that it's calling the two-argument std::condition_variable::wait. --Cubbi (talk) 07:00, 1 October 2014 (PDT)
Got it, thanks. I misread how the predicated wait works. But isn't the unsynchronized read/write on the variable 'processed' undefined behaviour? Shouldn't it be an atomic bool? Ens (talk) 12:06, 1 October 2014 (PDT)
The access to processed is synchronized: both the write in worker_thread and the read in main's cv.wait take place with the mutex m locked. --Cubbi (talk) 14:54, 1 October 2014 (PDT)
You're right! Thanks for your patience. Ens (talk) 16:15, 1 October 2014 (PDT)

[edit] Display quirk in definition of native_handle_type

The definition reads implementation-dened for me, although copy-pasting gives the correct implementation-defined, and in the source, there it’s also spelled out correctly … I’m using Fx 12.0 here, are there any people with similar problems? Fast2, 16:21, 5 June 2012 (PDT)

[edit] Need to simplify the example, and replace bool and while on the enum and switch.

( 30 Nov. 2012.