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 |