From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-03-18 18:51:30
Thanks to post your implementation on the vault.
Vicente Juan Botet Escriba
----- Original Message -----
From: "klaus triendl" <klaus_at_triendl.eu>
Sent: Tuesday, March 18, 2008 10:20 AM
Subject: Re: [boost] [thread] Interest in a locking pointer and
> vicente.botet schrieb:
>>> Inspired by Andrei Alexandrescu's article "volatile - Multithreaded
>>> Programmer's Best Friend" on ddj I implemented a concept similar to a
>>> locking pointer called "lock_acquirer" that collects acquisition of a
>>> mutex and a volatile cast of the locked type. It is even more threadsafe
>>> to use than a locking pointer.
>> I'm interested in your implementation, but much more in seen how this
>> lock_acquirer differs from the locking_ptr and in seen how it can works
>> the shared mutex.
>> Could you be more explicit about how it is more threadsafe?
>> There are other locking pointer like inspired also by Andrei
>> work that will be interesting as
>> on_derreference_locking_ptr(on_derreference_lock_acquirer) and
> Hi Vicente,
> I expressed myself too vague - the lock_acquirer itself isn't more
> threadsafe than a locking_ptr but the way the programmer has to use it
> leads to more threadsafe programming behaviour, I believe. Everything
> depends on the usage scenario, of course.
> A locking_ptr takes the lockable (locker, or whatever you call it) and
> provides access via operator ->() and operator *(); thus you can write:
> lockable<T, mutex> l;
> T* p = locking_ptr<lockable<T, mutex> >(l).operator ->();
> T& o = *locking_ptr<lockable<T, mutex> >(l);
> ... constructing the locking_ptr and accessing an object in a single line.
> lock_acquirer doesn't aim to be a smart pointer (though I like also the
> idea of having an automatic locking while accessing an object's method).
> It is constructed from a lockable but access to the object is only
> granted via a protected friend template function forcing to pass a named
> lock_acquirer object:
> lockable<T, mutex> l;
> lock_acquirer<lockable<T, mutex> > a(l);
> T& o = access_acquiree(a);
> An additional bonus of lock_acquirer is that the programmer can specify
> a locking policy (read/write) as a template parameter and the
> lock_acquirer selects an appropriate r/w lock for the given mutex type.
> If the locking policy is read access then lock_acquirer grants
> const-access only to the synchronized object even if T in lockable<T> is
> lockable<int, mutex> l;
> // readlock_acquirer derives from
> // lock_acquirer<readlock, lockable<int, mutex> >
> readlock_acquirer<lockable<int, mutex> > a(l);
> const int& o = access_acquiree(a);
>>> Also, the locked type in a lockable can, if wanted, by a restricted
>>> interface only be accessed by a lock_acquirer thus forcing the
>>> programmer to a very threadsafe programming style.
>> Could you show us how?
> The lockable type has public access methods, a safe_lockable however
> makes lock_acquirer a friend:
> template<typename T, typename T_mutex>
> struct safe_lockable: public lockable_base<T_mutex>
> template<...> friend class lock_acquirer;
> volatile_T& access_volatile();
> T& access_nonvolatile();
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk