Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>I.e. it is just thin wrapper around condition_variable+mutex.</p> </blockquote> <p>Er, no. Just because it has members of those types doesn't make it a thin wrapper. Try to understand what it actually does, not just the types of its private members. There's some quite subtle code there.</p> <blockquote> <ol> <li>Is it thread-safe to not protect notify_one by mutex for either condition_variable_any or condition_variable?</li> </ol> </blockquote> <p>Yes.</p> <p>In fact, calling <code>notify_one()</code> with the mutex locked will cause waiting threads to wake up, attempt to lock the mutex, find it is still locked by the notifying thread, and go back to sleep until the mutex is released. </p> <p>If you call <code>notify_one()</code> without the mutex locked then the waking threads can run immediately.</p> <blockquote> <p>2 Why implementation of condition_variable_any uses additional mutex?</p> </blockquote> <p><code>condition_variable_any</code> can be used with any <em>Lockable</em> type, not just <code>std:mutex</code>, but internally the one in libstdc++ uses a <code>condition_variable</code>, which can only be used with <code>std::mutex</code>, so it has an internal <code>std::mutex</code> object too.</p> <p>So the <code>condition_variable_any</code> works with two mutexes, the external one supplied by the user and the internal one used by the implementation.</p> <blockquote> <p>3 Why implementation of condition_variable_any::notify_one and condition_variable::notify_one differs? Maybe condition_variable::notify_one requires manual protection but condition_variable_any::notify_one doesn't? Is it libstdc++ bug?</p> </blockquote> <p>No, it's not a bug.</p> <p>The standard requires that calling <code>wait(mx)</code> must atomically unlock <code>mx</code> and sleep. libstdc++ uses the internal mutex to provide that guarantee of atomicity. The internal mutex must be locked to avoid missed notifications if other threads are just about to wait on the <code>condition_variable_any</code>.</p>
    singulars
    1. This table or related slice is empty.
    1. PODo I need to synchronize std::condition_variable/condition_variable_any::notify_one
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJonathan Wakely
    1. USJonathan Wakely
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PODo I need to synchronize std::condition_variable/condition_variable_any::notify_one
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks! That helped me a lot. Espeically answer to 2 and 3 - good point about atomicity, and inner stuff that uses mutex anyway. By the way, you may add link to pthread_cond_wait http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_wait.html to show that most common implementation works only with it's own mutex in internals. Could you please clarify what exactly do you mean on "there's some quite subtle code there.".
      singulars
      1. PO
      1. USqble
    2. CORegarding 1. - can non-locked condition_variable::notify_one lead to missed notifications? I.e. thread #1 does job under mutex, send result, unlock mutex, [meanwhile] thread #2 locks mutex but not yet called wait, [meanwhile] thread #1 calls notify_one, [meanwhile] thread #2 calls wait - notification is lost.
      singulars
      1. PO
      1. USqble
    3. COThat's not a lost notification, that's the waiting thread not checking the condition predicate before waiting. Locking the mutex doesn't help that situation, the notification could still come before the waiting thread locks the mutex. You **must** check the associated predicate when waiting on a condition variable
      singulars
      1. PO
      1. USJonathan Wakely
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload