$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.