StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>While I agree with your interpretation (and that of the Open POSIX test suite) of this language, usage will be implementation dependent. As such, here is a quick rundown of some of the major implementations:</p> <h2>Safe</h2> <ul> <li><strong>nptl</strong> - <code>pthread_cond_destroy()</code> will return <code>EBUSY</code> if there are threads still blocked on the condition. Destruction responsibility will pass to the threads that are signaled by not unblocked.</li> <li><strong>pthread-win32 MSVC</strong> - <code>pthread_cond_destroy()</code> will return <code>EBUSY</code> if there are threads still blocked on the condition. Threads that are signaled but not unblocked will be executed before <code>pthread_cond_destroy()</code> returns control to the application.</li> </ul> <hr> <h2>Safe but blocking</h2> <ul> <li><strong>Darwin libc-391</strong> - <code>pthread_cond_destroy()</code> will return <code>EBUSY</code> if there are threads still blocked on the condition. No provisions are made for blocked but signaled threads.</li> <li><strong>dietlibc 0.27</strong> - <code>pthread_cond_destroy()</code> will return <code>EBUSY</code> if there are threads still blocked on the condition. No provisions are made for blocked but signaled threads.</li> </ul> <hr> <h2>Possibly not safe</h2> <ul> <li><strong>Android</strong> - Depends on system implementation of <code>__futex_wake_ex</code> to be synchronous. Thus <code>pthread_cond_broadcast()</code> must block until all threads have woken (but not released their mutex).</li> <li><strong>various win32 implementations</strong> - Many rely on the <code>PulseEvent()</code> function to implement <code>pthread_cond_broadcast()</code>. This has a <a href="http://www.cs.wustl.edu/~schmidt/win32-cv-1.html" rel="nofollow">known race condition</a></li> </ul> <hr> <h2>Oddballs</h2> <ul> <li><strong>OSKit 0.9</strong> - Safe but returns <code>EINVAL</code> if <code>pthread_cond_destroy()</code> is called on a condition variable that is still referenced</li> </ul> <hr> <p><strong><em>Edit</em></strong></p> <p>The major issue, if I read your comments correctly is whether the <code>pthread_cond_wait()</code> can access the condition variable <em>before</em> it returns but <em>after</em> it is unblocked. And the answer is <strong>yes</strong>. The routine assumes that its arguments will remain valid.</p> <p>This means that after broadcasting, your thread cannot assume that the condition variable is unused by other threads.</p> <p>When you call <code>pthread_cond_broadcast()</code>, you do not acquire the associated mutex lock. While the threads waiting on your condition variable will execute sequentially, each acquiring the associated mutex in series. Because your waiters may block each other, your broadcasting thread may continue executing while waiters are still in <code>pthread_cond_wait()</code> blocked on the mutex (but not waiting for the condition).</p> <hr> <p><strong><em>Edit 2</em></strong></p> <blockquote> <p>[...]is it reasonable to expect unmapping to be valid in the same contexts destruction would be valid?</p> </blockquote> <p>I don't think that this is a reasonable expectation based on the reasoning in Edit 1. Additional synchronization would definitely be required if you are precluded from using <code>pthread_cond_destroy()</code> </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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