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:


> 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.


-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ - grafik/
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Boost list run by bdawes at, gregod at, cpdaniel at, john at