Boost logo

Boost :

From: Yitzhak Sapir (yitzhaks_at_[hidden])
Date: 2002-08-07 12:01:02


> From: William E. Kempf [mailto:williamkempf_at_[hidden]]
> From: "Yitzhak Sapir" <yitzhaks_at_[hidden]>
[posted from the end]
> > The effect is that you might provide a slightly better
> interface or one
> closer to the one you said you'd ideally like to have.
>
> Unless I'm missing something in your descriptions, I don't think so.

Since it's obvious to me that I did miss something, you did. I hope that my idea is worth something in the end.

> > Just an idea from following the discussion: Instead of
> calling the class
> "once", you could create an interface like this:
> >
> > boost::static_mutex_init -- equivalent of once_flag_type
> > boost::static_mutex is a regular class and is implemented
> like a mutex
> except it uses call_once mechanisms to make sure the mutex is
> initialized
> once in the constructor.
>
> This requires, again, for the boost::static_mutex to be a POD
> type, at which
> point the implementation can be made much simpler on most platforms.

boost::static_mutex_init is a POD type. Used something like this:
boost::static_mutex_init smi = BOOST_STATIC_MUTEX_INITIALIZER;
boost::static_mutex sm;

static_mutex can't be a POD because it is going to have a destructor (freeing the mutex). I can see now that it is calls to lock that are going to need smi as a parameter, and that the constructor is basically a no op. Inside lock, you'd do a call_once(CreateMutex, smi). Does this sound useful?

> Copyable semantics for mutex types is questionable at best. If it's
> basically a reference copy you only remove some of the dangers of this
> operation.

It is a reference copy (a copy of the shared_ptr). My purpose was to keep a reference count so that global client objects can access the static_mutex after main() has finished where destruction order of global objects may be different than what's needed for accessing the mutex. (In the first example, there isn't any copyable semantics). Since I don't know what dangers are involved, I'd thank you if you (or someone else) could refer me (maybe in private mail) to some article or anything explaining those dangers.

Thanks.
Yitzhak


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