Boost logo

Boost :

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


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.

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