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::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)

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.

([email protected]) 30 Nov. 2012.

Same mutex or NOT same mutex?

In the page for std::condition_variable it is mentioned:

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

But in the page for method std::condition_variable::notify_one, 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?