Boost logo

Boost :

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-11-15 23:57:06


Frank Mori Hess wrote:
> I've written a couple small classes to better support the creation of monitor
> objects, see:
>
> http://www.comedi.org/projects/libpoet/boostbook/doc/boostbook/html/poet/monitor_ptr.html

Interesting...

> I'd like to know if there's any interest in adding something like this to
> boost, and also looking for ideas on how to improve my implementation.

Since I have something similar in my own code I would certainly be
interested in a quick monitor utility. But...

> It
> works via a monitor_ptr class, which is like a shared_ptr with automatic
> mutex locking, plus an (optional) monitor_base class that lets classes
> managed by monitor_ptr do wait/notifies on a condition.

I wouldn't, and I didn't in my implementation, tie it directly to the
pointer concept. In most uses I've seen, i.e. my code, the monitored
object is not dynamically allocated and rather is embedded in a class.
That is I find myself converting existing class members to monitored,
rather than converting to a pointer (plus dynamic allocation). For example:

struct A
{
   monitor<int> count;

   int get_count() const;
   void set_count(int);
};

I also prefer manual RAII locking as it makes it clear the locked
scopes, and hence easier to debug locking problems. For example:

int A::get_count() const
{
   monitor<int>::scoped_lock count_(this->count);
   return *count_;
}

void A::set_count(int c)
{
   monitor<int>::scoped_lock count_(this->count);
   *count_ = c;
}

Note, I was lazy and opted for pointer semantics for the scoped_lock
since I wanted very simple code. But reference/value semantics might be
more appropriate. Especially since one might want a "monitor<
auto_ptr<A> >", for example.

HTH.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk