Talk:cpp/thread/condition variable

Broken Example
Tried with various compilers. Not working.

ticotico (talk) 13:31, 3 September 2021 (PDT)
 * which example, the one on cpp/thread/condition_variable? Works here --Cubbi (talk) 11:27, 4 September 2021 (PDT)
 * I should have clarified. It is the same example (https://en.cppreference.com/w/cpp/thread/condition_variable) and I tried with the Coliru compiler, different versions of gcc and clang offered.  It stays in the Building and running... phase and does not return.
 * Works for me in Coliru with all compilers --Ybab321 (talk) 08:02, 7 September 2021 (PDT)
 * I've noticed that, rather rarely, Coliru's site is not responsive, seems like internal maintenance or stuff like that. Also, sometimes Coliru stumbles upon some particular code and I guess that it might be the result of some (false positive) anti-vandalism protection triggering. Time and patience, and after a while everything is working fine again.) --Space Mission (talk) 11:29, 7 September 2021 (PDT)
 * You know, Goldbolt said he would be happy to be our examples code backend, if someone can find the time to set it up --Cubbi (talk) 12:43, 7 September 2021 (PDT)

No need to 2. check the condition... before cv.wait
Step 2, outlined as a MUST, is in fact completely unnecessary and futile, as the condition can trigger between this check and the call to cv.wait. The wait functions will immediately wake-up if the condition is already triggered. --Rustyx (talk) 06:36, 22 April 2020 (PDT)
 * You absolutely have to do it unless you are calling the overloads taking a predicate (which do it for you). T. Canens (talk) 06:48, 22 April 2020 (PDT)

(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. --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 is synchronized: both the write in worker_thread and the read in main's cv.wait take place with the mutex  locked. --Cubbi (talk) 14:54, 1 October 2014 (PDT)
 * You're right! Thanks for your patience. Ens (talk) 16:15, 1 October 2014 (PDT)

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, 87.175.137.51 16:21, 5 June 2012 (PDT)

Need to simplify the example, and replace bool and while on the enum and switch.
(a.rainman@gmail.com) 30 Nov. 2012.

Same mutex or NOT same mutex?
In the page for it is mentioned:

Any thread that intends to wait on std::condition_variable has to acquire a std::unique_lock, on the same mutex as used to protect the shared variable.

But in the page for method, the opposite is mentioned:

The notifying thread does not need to hold the lock on the same mutex as the one held by the waiting thread(s)

So what's actually needed?