1 |
On 2014-08-13, Andrés Becerra Sandoval <andres.becerra@×××××.com> wrote: |
2 |
|
3 |
> In short: |
4 |
> |
5 |
> Withouth the use of the lock, the condition variable and a shared |
6 |
> variable in concert you can get in trouble! |
7 |
|
8 |
That is often true, but |
9 |
|
10 |
1) I don't have a shared variable that I want to associate with the |
11 |
condition variable. There is some shared data, but I'm going to |
12 |
use means other than a mutex to control access to it. |
13 |
|
14 |
2) In most of the examples presented in that article the shared |
15 |
variable is an int that is set to 0 or 1 by one thread and is |
16 |
tested for non-zero value by the other. I'm not aware of any CPU |
17 |
on which Linux runs where those operations can result in a race |
18 |
condition thus requiring a mutex. [Yes I know that isn't |
19 |
guaranteed by the C language definiton, but one can verify that |
20 |
it's true.] |
21 |
|
22 |
If I create a shared mutex just to make pthread_cond_wait happy, and |
23 |
one of the "clients" (the ones calling pthread_cond_wait) dies while |
24 |
holding the mutex, then it deadlocks all of the other clients. To be |
25 |
safe it seems one should create a private mutex for each thread that's |
26 |
going to call pthread_cond_wait(). Private mutexes should be very |
27 |
little overhead in the uncontended case, so that's an option. |
28 |
|
29 |
-- |
30 |
Grant Edwards grant.b.edwards Yow! I wonder if I should |
31 |
at put myself in ESCROW!! |
32 |
gmail.com |