Re: [boost] Design and documentation of Boost.Threads

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
thread
> gets permanently starved.

Yup.

> But if the threads are not interchangeable (they
> have different functions, or correspond to different users or
transactions),
> then starvation is highly undesirable, and fairness is essential.  The
> strong mutex property (it is always some thread that was waiting at the
moment
> 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:

http://groups.google.com/groups?as_umsgid=3ACC9294.66B2B8EE%40compaq.com
http://groups.google.com/groups?as_umsgid=37B01650.F7DA4BD6%40zko.dec.com
http://groups.google.com/groups?as_umsgid=37B18626.C5ACBDD0%40zko.dec.com

> > > Atomic reads and writes
> > > -----------------------
> > >
> > > I think a discussion is needed of why even reads and writes of
variables
> > of
> > > primitive types may not be atomic, and that there is *one* type for
which
> > > 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
its
> use with signal handlers, but that is because the C standard doesn't
address
> multithreading at all.  Can you point me at any standards document that
states
> that objects of type sig_atomic_t may possibly not be accessed as an
atomic
> entity in a multithreaded program?

POSIX. http://groups.yahoo.com/group/boost/message/15526

regards,
alexander.