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