From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-31 15:19:30
--- In boost_at_y..., "Rainer Deyke" <root_at_r...> wrote:
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
> To: <boost_at_y...>
> 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?
I think you misunderstand me here. A lock_ptr<> is not a thread safe
shared_ptr<>, it's a completely new smart pointer that uses a proxy
class to lock a mutex before accessing the object through operator->
and unlock the mutex afterwards. It's an idea presented by Bjarne
Stroustrup, and it's very difficult to implement using only a Scoped
Lock. There are other cases that pose similar problems. The Scoped
Lock covers most use cases, but not all.
Bill Kempf