Re: [boost] Re: mutex_traits<>

From: Rainer Deyke (root_at_[hidden])
Date: 2002-01-31 14:46:00

----- Original Message -----
From: "bill_kempf" <williamkempf_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, January 31, 2002 11:49 AM
Subject: [boost] Re: mutex_traits<>

> Again, the free function approach doesn't discourage usage
> by "newbies".  I've seen many MT libraries that expose lock/unlock
on
> the mutex class's public interface (which is equivalent to free
> functions) as well as providing the Scoped Lock classes for "safer"
> usage.  Despite documentation warning of the issues most "newbies"
> invariably call lock/unlock directly instead of using the Scoped
> Lock, and the result is usually buggy programs that seem to run
> during testing but deadlock when software is released.  Maybe I'm
> trying to hard, but I want to prevent this newbie mistake while not
> preventing the experts from easily extending the library in ways
that
> scoped locking causes problems.

Can't the "advanced" mechanisms be implemented in terms of a scoped
lock, i.e.?

  shared_ptr<scoped_lock> shared_access_lock(new scoped_lock);

Or maybe the advanced features could be member fuctions of
'scoped_lock':

  class scoped_lock {
    scoped_lock(mutex&, bool initially_locked = true);
    void lock();
    void unlock();
    bool is_locked() bool;
    ~scoped_lock() { this->unlock(); }
  };

Is it really necessary to expose raw lock/unlock functions at all?

--
Rainer Deyke | root_at_[hidden] | http://rainerdeyke.com