|
Boost : |
From: scleary_at_[hidden]
Date: 2000-08-08 14:53:29
> > class mutex {
> > private:
> > pthread_mutex_t me;
> > mutex(const mutex &);
> > void operator=(const mutex &);
> > public:
> > mutex() { pthread_mutex_init(&me, 0); }
> > ~mutex() { pthread_mutex_destroy(&me); }
> > void lock() { pthread_mutex_lock(&me); }
> > void unlock() { pthread_mutex_unlock(&me); }
> > bool trylock() { return !pthread_mutex_trylock(&me); }
> > };
>
> This is the kind of interfaces I want to avoid! You can lock the mutex
> without automatic release. This wrapper is clearly too thin.
For my Win32-based threads programming, I use something similar to the above
for the actual mutex. An "auto_unlock" or "guard" class is a different
object. The "mutex" class is not designed to ensure unlocking the mutex,
but rather the destruction of the mutex when it is no longer needed.
> I don't think mutex can be copied.
Agreed. "auto_unlock" or "guard" classes can allow copying in an
auto_ptr-like fashion.
-Steve
P.S. Notes on terminology: "auto_unlock" simply unlocks the lock in its
destructor, whereas "guard" will lock the lock in its constructor *and*
unlock the lock in its destructor -- that's the only difference.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk