1 |
This is not Gentoo specific, and while I'm doing my prototyping and |
2 |
development on a Gentoo system, the eventual target is not going to be |
3 |
running Gentoo -- so feel free to ignore this thread or throw things |
4 |
at me. |
5 |
|
6 |
I'm trying to figure out how to synchronize threads which may be in |
7 |
different processes. Basically, I want thread A to be able to wake up |
8 |
any number of other threads B, C, D, ... who are all blocking until A |
9 |
says "go" (and who may or may not be in other processes). |
10 |
|
11 |
Other (mostly embedded) OSes I've used had some sort of "event flag" |
12 |
API that did exactly what I'm looking for, but I can't seem to find |
13 |
such a thing in pthreads. |
14 |
|
15 |
A condition variable in shared memory is the closest thing I have |
16 |
found, and my test applications are working OK (so far). But, I'm |
17 |
unclear on the purpose of the mutex whose address you pass to |
18 |
pthread_cond_wait(). |
19 |
|
20 |
Is it to prevent race conditions when manipulating the condition |
21 |
variable's internal state? I don't see how that can be the case, since |
22 |
the signal/broadcast call would have to be aware of it and it isn't. |
23 |
|
24 |
The mutex appears to be there to serialize access to some user-defined |
25 |
variable(s) (outside the condition variable itself) which I don't |
26 |
have. So all the mutex locking/unlocking and resultant blocking of B, |
27 |
C, D is just wasted overhead and pointless latency. |
28 |
|
29 |
pthread_cond_wait(3) says |
30 |
|
31 |
When using condition variables there is always a Boolean predicate |
32 |
involving shared variables associated with each condition wait that |
33 |
is true if the thread should proceed. Spurious wakeups from the |
34 |
pthread_cond_timedwait() or pthread_cond_wait() functions may |
35 |
occur. Since the return from pthread_cond_timedwait() or |
36 |
pthread_cond_wait() does not imply anything about the value of this |
37 |
predicate, the predicate should be re-evaluated upon such return. |
38 |
|
39 |
I have no "Boolean predicate" (which presumably comprises the |
40 |
"user-defined variables outside the condition variable" I mentioned |
41 |
above), and I don't want spurious wakeups, so a pthreads condition |
42 |
variable would appear to be the wrong thing to use. |
43 |
|
44 |
Is there something like an "event flag" similar to a condition |
45 |
variable without spurious wakeup problem and without the extra |
46 |
overhead of the mutex and "Boolean predicate". |
47 |
|
48 |
Or am I expected to build my own "event flag" using the aforesaid |
49 |
"boolean predicate" just to avoid the spurious wakeup problem? [I'm |
50 |
guessing this is the case...] |
51 |
|
52 |
-- |
53 |
Grant Edwards grant.b.edwards Yow! I'm DESPONDENT ... I |
54 |
at hope there's something |
55 |
gmail.com DEEP-FRIED under this |
56 |
miniature DOMED STADIUM ... |