tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pthread_cond_signal() ambiguity

On 01/23/10 21:58, David Holland wrote:
On Thu, Dec 03, 2009 at 10:30:57AM +0100, Jean-Yves Migeon wrote:
David Holland wrote:
Or wait forever, as it will race against the pthread_cond_signal: thread A
acquires the mutex, check condition, but thread B signals a condition
change between A wait for it; as B did not acquire the mutex, thread A
might not see the signal.

This cannot happen. In order to actually change the condition, B has
to hold the mutex.  It doesn't matter when B signals the change as long
as it's not *before* it changes the condition. (But that would be a
crazy thing to do, so it's not worth thinking about.)

Never said that B changes the condition. I said that B signals a change.
You have the right to call pth_cd_signal() without enforcing that the
caller modified the condition.

Yes, you also have the right to execute *(int *)0xdeadbeef = 172.
Both are wrong and will lead to problems.  Your point?

Periodic wakeups, or condvar modification performed in a context different from the one signaling. I do not see how this is wrong or leads to problems. Please elaborate.

Jean-Yves Migeon

Home | Main Index | Thread Index | Old Index