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

[Alan McKinnon]

On 13/08/2014 19:21, Grant Edwards wrote:
> 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).


Sounds like you a "one talker - many listeners" model. Have you
considered a really simple solution like dbus?



>
> 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...]
>


-- 
Alan McKinnon
alan.mckinnon@×××××.com