|
Boost : |
Subject: Re: [boost] [RFC] thread::access_monitor
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-05-14 11:58:14
Hi,
----- Original Message -----
From: "Gregory Petrosyan" <gregory.petrosyan_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, January 10, 2009 6:19 PM
Subject: [boost] [RFC] thread::access_monitor
>
> I would like to hear your comments on the idea behind access_monitor
> template, which ensures (at compile-time) that data, protected by it,
> can be accessed only with associated lock held. It can be useful when
> you want to expose all the native interface of your data type (STL
> container, for example): in such a case, using ordinary monitor
> pattern is almost impossible.
I don't know if you know Boost.Synchro (https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Synchro). Synchro contains a locking_ptr class that seems to do something similar, but the mutex storage is external to the class.
> Example usage:
>
> typedef access_monitor<data_type, mutex_type> data_access_monitor;
>
> void f(data_access_monitor const& d)
> {
> data_access_monitor::value_type const* data;
> data_access_monitor::lock_type lock;
>
> boost::tie(data, lock) = d.const_lock();
>
> // do something with data here
> }
void f(data_type const& d)
{
locking_ptr<data_type, mutex_type> data(d,mtx_); // the mytex is locked during the lifetime of data.
// do something with data here
}
This seems more compact, isn't it?
If you need to lock several objects with the same mutex at the same time you can use a externally_locked.
typedef externally_locked<data_type, mutex_type> data_access_monitor;
void f(data_access_monitor const& d1, data_access_monitor const&d1)
{
strict_locker<mutex_type> guard(mtx);
data_type const* data1= d1.get(guard); // data can be obtained if provided a strict_locker
data_type const* data2= d2.get(guard); // data can be obtained if provided a strict_locker
// do something with data1 and data2 here
}
What do you think about these classes?
Best,
Vicente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk