Re: [boost] [thread] condition suffering from lost wakup bug?

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-09-15 01:24:51

Matt Hurd schrieb:

>>    { // we wait until all threads are up
>>        lock_type lock(guard);
>>        while (global_number_of_threads <
>>            number_of_threads_for_test+1)
>>            cond.wait(lock);
>>    }
>>    
>>
>
>I can't see why you get here?  I might be missing something but you're
>likely to end up with all threads waiting on conditions here...
>
This is intentionally, since I need to create a "thundering herd here".

    for (long j=0; j<count_for_test; ++j) {
        lock_type lock(guard);
        ++global_count;
        // Step 1: We do a heavy notification
        cond.notify_all();
        // Step 2: Then we wait on the same condition.
        // Since we hold the lock we can be sure
 

The notify_all unlocks them. And every thread should bet a chance to run.
They are going to sleep agin soon, however this is not of importance.
The importance is the relative sequence:

t1: Main signals
t2: Main waits
t3: do_flag signals, and this signal occasionally is beeing lost.

Some background: When the unblocking starts, the condition internally
closes a gate. During the closed gate new waiters are blocked
off but not counted yet. Unfortunately if there now is a another
signal, the signal is not counted too and when the gate is opened again
the threads that queued up front gate will come in and get counted.
Unfortunately they cannot be unblocked by the signals that followed
them while the gate was closed, since they havent been counted too.

The time that the gate is closed is
usually short but not zero. Now it happens that, when during this
time the sequence: wait, signal does happen the signal is lost.

My thundering herd is just a simple means to keep the gate
closed long enough to make the probaility of this event higher.
But it can happen in principle also during normal operation.
The probaility just is so low.

The do_flag() is in the same pool and beeing scheduled
sooner or later. Now it happens that on occassion it indeed
is getting scheduled so soon to fall into the gate, and
consequently deadlocks.

Regards,
Roland