Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at