Re: How to wait for multiple threads simultaneously?

On Feb 15, 1:33 pm, David Schwartz <dav...@xxxxxxxxxxxxx> wrote:
On Feb 15, 3:14 am, Rainer Weikusat <rweiku...@xxxxxxxxxxx> wrote:

And this actually nicely illustrates why using established terms to
express different meanings is a bad idea: Your idea of a condition
variable is quite obviously not something which causes a thread to
sleep until woken up, but some basically purposeless addition to a
loop which is busy-waiting until some condition is true.

I honestly can't understand what you're talking about at this point.

DS

Actually, maybe I see what the issue is. You think that condition
variables are tested in 'while' loops because of spurious wakeups and
thundering herds. But again, that is not true. Condition variables are
tested in 'while' loops because even with perfectly correct code, no
thundering herds, and no spurious wakeups, another thread *still* can
have consumed the event.

In other words, looping in the 'while' loop is still perfectly normal
behavior.

Consider a typical thread pool with a condition variable that threads
block on when there are no jobs in the queue. Suppose one thread is
working on a job while another thread puts a job on an empty queue.
The thread that placed the job on the queue calls
'pthread_cond_signal' and one blocked thread is woken. Before that
thread is scheduled, the thread that was working on a job may complete
that job and return to its own 'while' loop, which it will leave
immediately when it consumes the job. At this point, the thread that
wakes up due to the signal will find the queue empty and have to loop
again.

The thread can do nothing until it happens to get scheduled while a
job happens to be on the queue. It will loop as many times as it has
to until this is the case. Whether this consumes the CPU or blocks, it
can be referred to as "spinning" simply because code runs and no
forward progress is made.

If you look at the POSIX definition of a "spin lock", nowhere does it
require busy waiting. It simply requires that the lock function not
return until the lock is acquired. It is perfectly reasonable to refer
to acquiring such a lock as "spinning" even if the implementation does
not busy wait. So long as code may run in a tight loop without making
forward progress until something 'external' happens, the code is
spinning.

DS
.

Relevant Pages

  • Re: [PATCH [RT] 08/14] add a loop counter based timeout mechanism
    ... At first we only had the adaptive wait added to the rt spin lock code, ... Note that the adaptive wait loop breaks on every owner change, ... is stolen from the pending owner, in which case the pending owner can ... and will iterate and again start spinning. ...
    (Linux-Kernel)
  • Re: Delaying events for fixed amounts of time.
    ... amount of time after the *FIRST* event with a given key arrives. ... I have anything Windows has to offer. ... Pause for, say, 250ms each time through the loop ... Have a queue of keys, each time a new key arrives, add it to the end ...
    (comp.programming.threads)
  • Re: Threading help... threads???
    ... it appears as if you have an endless loop. ... remove the call record from the queue and make the call. ... End Sub ... 'derived classes must override. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Delaying events for fixed amounts of time.
    ... amount of time after the *FIRST* event with a given key arrives. ... Process events as timers expire. ... Pause for, say, 250ms each time through the loop ... Have a queue of keys, each time a new key arrives, add it to the end ...
    (comp.programming.threads)
  • Re: Threading help... threads???
    ... that it sat in a loop doing the following ... > queue" to see if there were any calls to be made. ... > Protected Overrides Sub Execute() ...
    (microsoft.public.dotnet.languages.vb)