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

From: Kevin S. Van Horn (kevin.vanhorn_at_[hidden])
Date: 2001-11-14 10:27:47

On Wed, 14 Nov 2001, Alexander Terekhov wrote:

> Ah, in other words, you want some threads to be given
> "equitable" shares of everything they compete (mtx:lock,
> condvar:wait&lock) for, right?

No.  You misunderstand what "fairness" means.

> "Fairness" is relative, subjective, and
> usually isn't actually what anyone wants when they ask for it.

No, there is a precise technical meaning of "fairness" in the literature
on correctness proofs for concurrent programs.  "Fairness" in this sense
has nothing to do with getting a "fair" share of anything; it merely means
lack of starvation, i.e., getting a *nonzero* share.  If threads A and B
are in loops competing for a mutex and thread A gets the mutex 10 times
for every time B gets it, this is still fair.  It becomes unfair if A
manages to completely crowd out B so that B *never* gets the mutex again.

You keep on claiming that fairness is inefficient because of context
switches.  That may be an argument against strong mutexes, but as I
mentioned in another message, it is possible to have weak but fair
mutexes, and such a thing would handle your concerns about minimizing
context switches while also handling my concerns about starvation.

> Well, so far, I've never
> had a problem with respect to "weak" mutexes/condvars.

That doesn't mean much.  Latent errors that don't manifest themselves
until the right combination of conditions occurs are much more common in
multithreaded programs than they are in single-threaded programs.

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

Ah.  I had not considered the issue of cache coherency.  OK, I agree with
you on this one.