Boost logo

Boost :

From: jsiek_at_[hidden]
Date: 2000-08-14 21:03:14


William Kempf writes:
> This supposes that there's ever a reason to have a Mutex instead of a
> MutexWithCV. I'm not sure that the plain Mutex concept is ever
> really valid. I realize that this is a shakey argument on my part,
> so maybe I should abandon it. I guess I just don't feel good doing
> that just yet. The nesting appeals to me, and I guess it will
> continue to until you can point out why it's appropriate for lock but
> not for condition. Or, put in another way, why would we ever have a
> concrete mutex type with out an associated concrete condition type?

To explain why we need plain Mutex a a concept I'll take a little step
back... The purpose of a concept is to describe the requirements
placed on a template argument by a template function or class. Now a
template function or class is more reusable the more abstract, or the
fewer the requirements on the template arguments. I call this the
"requirement minimization principal". Anotherwords, a template
function should always pick the minimal concept that "covers" the
function's requirements. Now it is easy to think of situations where a
particular template function would need a Mutex and not a
ConditionVariable, say to protect access to a global variable. For
this template function we need a concept to describe the
requirements. The right choice is Mutex and not MutexWithCV because of
the minimization principal.

I have a slightly longer discussion of concept design, and
concept checking in a paper I just submitted for the NetObjectDays
template workshop:

http://www.lsc.nd.edu/~jsiek/concept_checking.pdf

Cheers,
Jeremy

----------------------------------------------------------------------
 Jeremy Siek www: http://www.lsc.nd.edu/~jsiek/
 Ph.D. Candidate email: jsiek_at_[hidden]
 Univ. of Notre Dame cell phone: (415) 377-5814
----------------------------------------------------------------------


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk