-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 15 November 2007 23:57 pm, Rene Rivera wrote:
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 assume a monitor<T> requires that T be copy-constructible? I guess that's not a big deal, since T could be made a pointer type, or a boost::ref. I would have liked to have separated out the smart_ptr from the monitor functionality but didn't see a really good way to do so in keeping with the pointer concept. It isn't absolutely required to do dynamic allocation of the "owned" object though, since you can create a monitor_ptr from a shared_ptr with a null deleter, which can in turn be created from a pointer to the stack.
I also prefer manual RAII locking as it makes it clear the locked scopes, and hence easier to debug locking problems. For example:
I like being able to use the monitor_ptr directly without having to explicitly create another object first. However, I can certainly imagine cases where being able to make multiple member function calls without releasing the lock in between would be convenient. It wouldn't be hard to add this, a monitor_ptr::scoped_lock would basically be a monitor_call_proxy with a public constructor. Also, if it provided wait/notify functions, it would be possible to extend a monitor using free functions with full access to the monitor functionality. Actually, with a monitor_ptr::scoped_lock the internal boost::condition might be dropped entirely. The monitor_base class could just provide a reference to the current scoped_lock and a derived class could pass the scoped_lock to the wait() functions of its own conditions (of which it could have more than one). I don't know, maybe I am too attached to the idea of using monitor_ptr directly as a smart pointer. A shared ownership pointer seems natural in a way though, since multiple pointers/references to a single monitor object will inevitably be passed around to multiple threads.
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.
You mean make it act like a "smart reference" instead of a "smart pointer"? I don't know how to do that. The way operator->() works must have been designed to support smart pointers, but operator.() isn't overloadable at all? Maybe some kind of reflection library could do the magic? The monitor<auto_ptr<A> > case seems workable if your scoped_lock class has an explicit get() function that returns the underlying pointer (in this case a auto_ptr<A>*). - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQFHPbAw5vihyNWuA4URAiuAAJY9CZGdwL0jDrYNBuhhnL73/bDSAJ0dHeyz 4xiGlHzVlVNTfRgBL3yBWw== =t9+i -----END PGP SIGNATURE-----