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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-11 23:20:44

----- Original Message -----
From: "Kevin S. Van Horn" <kevin.vanhorn_at_[hidden]>

> 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. It was much more
efficient for a single thread to be allowed to re-acquire the mutex multiple
times before another waiting thread was allowed to unblock.

> Handling of programmer errors
> -----------------------------
>
> There are many places where the documentation specifies that exceptions
*will*
> be thrown if some precondition is not met.  Do you really want to
guarantee
> this, or do you just want to say that the exception *may* be thrown?  At
debug
> time you do not want exceptions thrown for what amounts to programmer
error
> (e.g., unlocking a mutex that you do not have locked), as this throws away
a
> lot of useful information as the stack unwinds.  At debug time it is much
> preferable for the program to dump core so that you can examine the core
dump
> with a debugger and have full information on the context of the error.  I
> recognize that a core dump is unacceptable for some production
environments,
> so it would be nice to be able to choose between the core-dump and
exception
> options via a compile-time flag.

I agree with Kevin about this.

> 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. I'm pretty sure you can't add much useful
information even now since the throw sits within the thread library code.

-Dave