Re: [gentoo-user] OT: pthreads condition variable/mutex question

["Andrés Becerra Sandoval" <andres.becerra@gmail.com>]

2014-08-13 12:36 GMT-05:00 Andrés Becerra Sandoval <andres.becerra@gmail.com>:
> 2014-08-13 12:21 GMT-05:00 Grant Edwards <grant.b.edwards@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