Re: [boost] [thread] RFC standard proposed mutex, read-write mutex, condition

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-08-21 14:21:49

Howard Hinnant wrote:

> I'm not concerned about running out of memory.  I'm concerned about
> generating more L1 cache misses.

A valid point, especially if sizeof(pthread_cond_t) is 4 or 8.

> We have several opposing use cases we need to satisfy with
> std::condition:
>
> 1.  Minimum size - performance overhead.
> 2.  The freedom to dynamically associate mutexes with condition
> variables.
> 3.  The ability to apply run time check consistency concerning the
> associated mutex.
> 4.  The ability to wait on general mutex / lock types.

I'd suggest a different approach in meeting these needs. Remove the "shall 
throw on error" requirement and replace it with a Requires clause that says 
that lk.mutex() must be equal to the address of the constructor argument, if 
supplied.

Now:

1. Enabled by compiling against the release runtime.

1a. Minimum size, almost no performance overhead: enabled by compiling 
against the "checked release" runtime that does not increase 
sizeof(std::condition) and as a result may miss some errors.

2. Enabled by not passing a mutex in the constructor.

3. Enabled by passing a mutex in the constructor and compiling against the 
debug runtime.

4. As before.

Switching between 1/1a/3 requires no source changes. Switching between 1 and 
1a requires no recompilation. If binary compatibility between 1 and 3 is 
desired, it could be possible to engineer the debug runtime to meet this 
case as well, even though it would be less convenient and possibly carry 
more overhead than just storing a mutex* in the condition.