Re: [boost] Re: Move semantics (was: Boost.Threads Locking Dilemma)

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-05-17 09:28:04

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, May 17, 2002 5:16 AM
Subject: Re: [boost] Re: Move semantics (was: Boost.Threads Locking Dilemma)

> From: "David B. Held" <dheld_at_[hidden]>
> >
> > This doesn't have anything to do with threads, but it's interesting that
> > you found another possible use for move semantics.  I'm not sure if
> > you could create the lock you need out of a policy-based smart pointer,
>
> [...]
>
> Viewing a lock as a limited smart pointer, where the resource is acquired
> via mutex::do_lock and released via mutex::do_unlock is a powerful idea.
Now
> one can unleash the "smart pointer theory" on the problem. ;-)
>
> A quick-and-dirty prototype along these lines:
>
> class mutex
> {
>     mutex * do_lock()
>     {
>         // lock
>         return this;
>     }
>
>     void do_unlock();
>
> public:
>
>     class shared_lock;
>     friend class shared_lock;
>
>     class shared_lock
>     {
>         shared_ptr<mutex> sp_;
>
>     public:
>
>         explicit shared_lock(mutex & m): sp_(m.do_lock(),
> mem_fn(&mutex::do_unlock))
>         {
>         }
>     }
> };
>
> An interesting topic for research that may produce an article or even a
> series. It isn't a move semantics showcase IMHO but it's a good
> pro-smart_ptr example (compared to shared_ptr) and has an interesting
> chicken-and-egg subtlety w.r.t. the thread safety of the reference count.

I agree that it's interesting to research, but I *truly* think a SharedLock
concept would be a bad idea.  This will only encourage users to share the
lock in manners that are not safe, such as across thread boundaries.
Further, it makes it more difficult to control the precise lifetime of the
lock, which is something crucial for proper synchronization.  There are
similarities between the ScopedLocking pattern and smart pointers, but there
are enough differences to make a lot of the concepts that are valid for
smart pointers to be invalid (or at least dangerous) for "smart locks".

Bill Kempf
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>