Re: How to wait for multiple threads simultaneously?

On Feb 17, 11:12 am, Rainer Weikusat <rweiku...@xxxxxxxxxxx> wrote:

This is presumably an omission, because a 'POSIX spin lock' would not
be anyhow different from an ordinary mutex, then, and completely
redundant.

It is not *required* to be different. However, if it's redundant, then
so are condition variables, because you can always just release the
mutex, yield, and re-acquire the mutex. POSIX does not require that to
be different from phtread_cond_wait either.

A 'spin lock' is a synchronisation primitive intended for locks which
are only held for very short times on a multiprocessor, specifically,
for times which are short enough that the overhead of marking the
process/ thread as no longer runnable, switching to a different
'execution context', marking the process as runnable again and
switching back to it would be excessive when compared with the time
the lock is actually held. Instead of going to sleep, the process/
thread 'spins' in a loop, trying to reacquire the lock until that
succeeds. Combinations of both approaches exist, too, eg mutexes on
which a thread spins for a short time and if it couldn't acquire the
lock during this time, goes to sleep to avoid tying up a processor for
no particular reason.

Right, that is when you use a spin lock. But then it is the
implementation's decision what the right thing to do in that
circumstance is. For example, if there's only a single CPU, the
implementation may justifiably refuse to spin. The program can't know
whether spinning is appropriate, only that it believes circumstances
are such that it might be.

The point is, we call it "spinning" because it's a tight loop that
might consume CPU, not because it must busy wait. The implementation
need not busy wait if it knows that's not appropriate.

DS
.

Relevant Pages

  • Re: Recursive mutex that can be waited upon (pthread)
    ... While you can use a mutex to avoid that data is changed, for me having a mutex does not mean that data is not changed, it only means that data is not changed by a different thread. ... My own thread may of course change the data, hence functions I call may want to change the data and if they do so, they must be sure that these changes are atomically, hence they must lock the object and they simply can't rely that I locked the object before -> thus I need recursive locks. ... Then I could as well throw out threads of my code and just use a single thread going through an event queue. ... you have a predicate condition on an invariant. ...
    (comp.programming.threads)
  • [patch 6/8] mutex subsystem, core
    ... mutex implementation, core files: just the basic subsystem, no users of it. ... straightforward mutexes with strict semantics: ... + * Block on a lock - add ourselves to the list of waiters. ...
    (Linux-Kernel)
  • [patch 6/8] mutex subsystem, core
    ... mutex implementation, core files: just the basic subsystem, no users of it. ... straightforward mutexes with strict semantics: ... + * Block on a lock - add ourselves to the list of waiters. ...
    (Linux-Kernel)
  • [PATCH 4/8] adaptive real-time lock support
    ... The Real Time patches to the Linux kernel converts the architecture ... compromising the integrity of critical sections protected by the lock. ... while retaining both the priority inheritance protocol as well as the ... the RT Mutex has been ...
    (Linux-Kernel)
  • Re: WaitForSingleObject() will not deadlock
    ... You keep talking about needing to know the reference count. ... algorithm that uses a recursive mutex that cares in the slightest what the reference count ... attempts to lock appears to be isomorphic to a recursive lock, ... cycle detection until you reach the end of the list, ...
    (microsoft.public.vc.mfc)