Re: [boost] [rfc] thread-safe monitor objects

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-11-16 09:58:55

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