2014-08-13 12:36 GMT-05:00 Andrés Becerra Sandoval <andres.bece...@gmail.com>: > 2014-08-13 12:21 GMT-05:00 Grant Edwards <grant.b.edwa...@gmail.com>: >> This is not Gentoo specific, and while I'm doing my prototyping and >> development on a Gentoo system, the eventual target is not going to be >> running Gentoo -- so feel free to ignore this thread or throw things >> at me. >> >> I'm trying to figure out how to synchronize threads which may be in >> different processes. Basically, I want thread A to be able to wake up >> any number of other threads B, C, D, ... who are all blocking until A >> says "go" (and who may or may not be in other processes). >> >> Other (mostly embedded) OSes I've used had some sort of "event flag" >> API that did exactly what I'm looking for, but I can't seem to find >> such a thing in pthreads. >> >> A condition variable in shared memory is the closest thing I have >> found, and my test applications are working OK (so far). But, I'm >> unclear on the purpose of the mutex whose address you pass to >> pthread_cond_wait(). >> >> Is it to prevent race conditions when manipulating the condition >> variable's internal state? I don't see how that can be the case, since >> the signal/broadcast call would have to be aware of it and it isn't. >> >> The mutex appears to be there to serialize access to some user-defined >> variable(s) (outside the condition variable itself) which I don't >> have. So all the mutex locking/unlocking and resultant blocking of B, >> C, D is just wasted overhead and pointless latency. >> >> pthread_cond_wait(3) says >> >> When using condition variables there is always a Boolean predicate >> involving shared variables associated with each condition wait that >> is true if the thread should proceed. Spurious wakeups from the >> pthread_cond_timedwait() or pthread_cond_wait() functions may >> occur. Since the return from pthread_cond_timedwait() or >> pthread_cond_wait() does not imply anything about the value of this >> predicate, the predicate should be re-evaluated upon such return. >> >> I have no "Boolean predicate" (which presumably comprises the >> "user-defined variables outside the condition variable" I mentioned >> above), and I don't want spurious wakeups, so a pthreads condition >> variable would appear to be the wrong thing to use. >> >> Is there something like an "event flag" similar to a condition >> variable without spurious wakeup problem and without the extra >> overhead of the mutex and "Boolean predicate". >> >> Or am I expected to build my own "event flag" using the aforesaid >> "boolean predicate" just to avoid the spurious wakeup problem? [I'm >> guessing this is the case...] >> >> -- >> Grant Edwards grant.b.edwards Yow! I'm DESPONDENT ... I >> at hope there's something >> gmail.com DEEP-FRIED under this >> miniature DOMED STADIUM >> ... >> >> > > Hi Grant, > > The best explanation I have read is this chapter: > http://pages.cs.wisc.edu/~remzi/OSTEP/threads-cv.pdf > > from the book: > > http://pages.cs.wisc.edu/~remzi/OSTEP/ > > I know its 17 pages, but it is worth it! > > > -- > Andrés Becerra Sandoval
In short: Withouth the use of the lock, the condition variable and a shared variable in concert you can get in trouble! -- Andrés Becerra Sandoval
