Gentoo Archives: gentoo-user

From: "Andrés Becerra Sandoval" <andres.becerra@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] OT: pthreads condition variable/mutex question
Date: Wed, 13 Aug 2014 17:36:52
Message-Id: CACSNh6Mu+_RGjywVxQi-e_HGmeMBCwoiQ=0t7gBNo-Q0pHWc_w@mail.gmail.com
In Reply to: [gentoo-user] OT: pthreads condition variable/mutex question by Grant Edwards
1 2014-08-13 12:21 GMT-05:00 Grant Edwards <grant.b.edwards@×××××.com>:
2 > This is not Gentoo specific, and while I'm doing my prototyping and
3 > development on a Gentoo system, the eventual target is not going to be
4 > running Gentoo -- so feel free to ignore this thread or throw things
5 > at me.
6 >
7 > I'm trying to figure out how to synchronize threads which may be in
8 > different processes. Basically, I want thread A to be able to wake up
9 > any number of other threads B, C, D, ... who are all blocking until A
10 > says "go" (and who may or may not be in other processes).
11 >
12 > Other (mostly embedded) OSes I've used had some sort of "event flag"
13 > API that did exactly what I'm looking for, but I can't seem to find
14 > such a thing in pthreads.
15 >
16 > A condition variable in shared memory is the closest thing I have
17 > found, and my test applications are working OK (so far). But, I'm
18 > unclear on the purpose of the mutex whose address you pass to
19 > pthread_cond_wait().
20 >
21 > Is it to prevent race conditions when manipulating the condition
22 > variable's internal state? I don't see how that can be the case, since
23 > the signal/broadcast call would have to be aware of it and it isn't.
24 >
25 > The mutex appears to be there to serialize access to some user-defined
26 > variable(s) (outside the condition variable itself) which I don't
27 > have. So all the mutex locking/unlocking and resultant blocking of B,
28 > C, D is just wasted overhead and pointless latency.
29 >
30 > pthread_cond_wait(3) says
31 >
32 > When using condition variables there is always a Boolean predicate
33 > involving shared variables associated with each condition wait that
34 > is true if the thread should proceed. Spurious wakeups from the
35 > pthread_cond_timedwait() or pthread_cond_wait() functions may
36 > occur. Since the return from pthread_cond_timedwait() or
37 > pthread_cond_wait() does not imply anything about the value of this
38 > predicate, the predicate should be re-evaluated upon such return.
39 >
40 > I have no "Boolean predicate" (which presumably comprises the
41 > "user-defined variables outside the condition variable" I mentioned
42 > above), and I don't want spurious wakeups, so a pthreads condition
43 > variable would appear to be the wrong thing to use.
44 >
45 > Is there something like an "event flag" similar to a condition
46 > variable without spurious wakeup problem and without the extra
47 > overhead of the mutex and "Boolean predicate".
48 >
49 > Or am I expected to build my own "event flag" using the aforesaid
50 > "boolean predicate" just to avoid the spurious wakeup problem? [I'm
51 > guessing this is the case...]
52 >
53 > --
54 > Grant Edwards grant.b.edwards Yow! I'm DESPONDENT ... I
55 > at hope there's something
56 > gmail.com DEEP-FRIED under this
57 > miniature DOMED STADIUM ...
58 >
59 >
60
61 Hi Grant,
62
63 The best explanation I have read is this chapter:
64 http://pages.cs.wisc.edu/~remzi/OSTEP/threads-cv.pdf
65
66 from the book:
67
68 http://pages.cs.wisc.edu/~remzi/OSTEP/
69
70 I know its 17 pages, but it is worth it!
71
72
73 --
74 Andrés Becerra Sandoval

Replies

Subject Author
Re: [gentoo-user] OT: pthreads condition variable/mutex question "Andrés Becerra Sandoval" <andres.becerra@×××××.com>