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

From: Kevin S. Van Horn (kevin.vanhorn_at_[hidden])
Date: 2001-11-13 10:08:53

On Mon, 12 Nov 2001, Alexander Terekhov wrote:

>
> > 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.  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.

> > 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?  I don't see how sig_atomic_t *could* be
atomic for single-threaded programs with asynchronous signals but not be
atomic for multithreaded programs; in either case, the needed property is that
the CPU be able to read or write a value of that type with a single memory
access.  In any event, we could always define our own atomic integer type,
with a config file setting it to the integral type appropriate for each
CPU/compiler.