Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-11-13 19:26:46

> > > Fairness and strongness
> > > -----------------------
> > [...]
> > so what? why do you care which thread enters critical
> > section and does the mutually exclusive work?
> > fairness could only slow things down (e.g. "hot" thread(s)
> > would likely to do the work much faster than "cold" threads).
> If the threads are interchangeable then it doesn't really matter if one
> gets permanently starved.


> But if the threads are not interchangeable (they
> have different functions, or correspond to different users or
> then starvation is highly undesirable, and fairness is essential. The
> strong mutex property (it is always some thread that was waiting at the
> the unlock occurred that gets the mutex) is useful and often necessary to
> ensure lack of starvation.

Ah, in other words, you want some threads to be given
"equitable" shares of everything they compete (mtx:lock,
condvar:wait&lock) for, right? Well, so far, I've never
had a problem with respect to "weak" mutexes/condvars.
They are fast and portable. also, take a look at:

> > > Atomic reads and writes
> > > -----------------------
> > >
> > > I think a discussion is needed of why even reads and writes of
> > of
> > > primitive types may not be atomic, and that there is *one* type for
> > > reads and simple writes are guaranteed atomic (sig_atomic_t).
> >
> > static volatile sig_atomic_t vars only work with respect
> > to ONE thread and a signal-handler interrupting THAT thread.
> It is true that the C standard that defines sig_atomic_t only talks about
> use with signal handlers, but that is because the C standard doesn't
> multithreading at all. Can you point me at any standards document that
> that objects of type sig_atomic_t may possibly not be accessed as an
> entity in a multithreaded program?



Boost list run by bdawes at, gregod at, cpdaniel at, john at