Re: Pthread programming: about the lost condition signals.


Szabolcs Ferenczi wrote:

I am afraid your example has some logic and concurrency bugs whether
you use method one or method two.

You are correct. My example contains several defects. However, the
principle is correct.

One concurrency bug is that you must give a signal whenever you update
the shared variable and you miss to give any signal in your example.

No, you don't have to. The type A and type B threads resolve something
that is made to need resolution by other threads. They do not create
any situation that needs resolution by another thread.

If a thread makes the predicate true and it's supposed to be false, it
signals to get the appropriate A or B thread to fix the problem. If a
thread makes the predicate false and it's supposed to be true, it
signals to get the appropriate A or B thread to fix the problem. Once
the A or B thread runs, the job is done, and the predicate is as the
logic needs it.

Only the threads that "break" the predicate need to signal.

The third bug and this is the main one: If you mean to use one and the
same condition variable for the two different predicates, I think you
do, it is possible that the set of threads waiting on the same cv
contain both thread A and thread B types. Consequently, a signal on
the same cv may wake up the `wrong' thread whether method one or two
is used.

Yeah, you are correct. I can fix it by having the signalling thread
create the only type B thread while it holds the mutex. There are
better ways to fix it, and I've got a fixed example somewhere on
USENET. I failed in my attempt to hastily reconstruct it though.

The point stands though, there is a huge semantic difference when you
move pthread_cond_signal outside of the lock -- in one case you cannot
signal a thread that chose to block on the basis of the changed
predicate and in the other case you can.

As I showed though, it's hard to create a correct case where this
matters even when you're trying to do so. So the odds of encountering
one in the wild are basically zero.

The solution is either to use two distinct cv for the two predicates
or use broadcasts.

I agree. It's very hard to get a case where the same cv protects two
logically distinct predicates if you're going to signal rather than
broadcast.

DS
.

Relevant Pages

  • Re: Falcon threading module docs released.
    ... The condvar signals that there is a state change (e.g., predicate mutation). ...
    (comp.programming.threads)
  • Re: Threads, conditions, sockets, selects...
    ... race condition, and it has never been observed in the wild. ... Another thread changes the predicate, ... mutex before signalling. ... This is impossible if B signals while holding the mutex. ...
    (comp.unix.programmer)
  • Re: Pthread programming: about the lost condition signals.
    ... might end up with two waiters, only one of which will awaken with your ... point and no signals and every prior change in any predicate was ... As soon as you release the mutex, ... That presumes there have been prior signals. ...
    (comp.programming.threads)
  • Re: Forking from a thread?
    ... My fear is that the other thread will call the callback that signals ... protects the data items that make up the predicate, ... whatever action is appropriate and then release the mutex. ...
    (comp.unix.programmer)
  • Re: Threads, conditions, sockets, selects...
    ... One thread is blocked on the condition variable, waiting ... Another thread changes the predicate, ... mutex before signalling. ... This is impossible if B signals while holding the mutex. ...
    (comp.unix.programmer)