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
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk