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

From: Kevin S. Van Horn (kevin.vanhorn_at_[hidden])
Date: 2001-11-13 09:50:41

 On Sun, 11 Nov 2001, David Abrahams wrote:

> > 3. Fair mutexes.  A fair mutex is a strong mutex with one additional
> > guarantee: as long as every thread that acquires the mutex eventually
> releases
> > it, any thread that is blocked on the mutex will eventually require it.
> Note
> > that mutexes that use FIFO scheduling are fair, but a mutex can be fair
> > without using FIFO scheduling.
>
> Yes, and I recently spoke with someone for whom an "overly fair" mutex was
> extremely inefficient. I think the problem was FIFO scheduling, so it's
> probably possible to have had a sufficiently efficient fair mutex, but the
> issue was that there were too many context switches.

If need be, I could see providing different mutexes with different tradeoffs
between efficiency and lack of starvation.  I think it's important to have
fair mutexes available, though, because library users won't be able to easily
provide these for themselves.  (In fact, I don't think they can build fair
mutexes on top of weak mutexes at all.)  I also have to say that I suspect
that anyone who discards lack-of-starvation guarantees to improve performance
is going to regret it in the end, as they will be vulnerable to intermittent,
mysterious thread hang-ups.

You know, there is another possibility I didn't mention: a mutex that is weak
but fair.  Such a beast might address both the context-switching and
starvation concerns.

> > In addition, I would suggest that even when you do throw an exception, the
> > exception object should include the file and line number.  (See discussion
> > below for overview.html.)
>
> I don't think I agree about that, except when exceptions are thrown as part
> of the undefined behavior resulting from a failed precondition. Even then,
> as code becomes increasingly encapsulated, the originating file and line
> become increasingly useless.

However it's done, I think you need to provide sufficiently detailed
information to identify the library call that went wrong and the precise
nature of the error.