Re: [boost] boost] [thread] Interest in a locking pointer and lockable concept

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-03-24 10:49:53

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 23 March 2008 18:47 pm, Phil Endecott wrote:
> The point is that all of the values share a mutex.  Our Lockable<>
> classes could be used here if you wanted one mutex per value, but that
> could be wasteful and perhaps wrong.  How can we adapt Lockable<> to
> work in this sort of situation?  I'm wondering about something like this:
>
> Lockable< array<int,100 > values;
>
> for (int i=0; i<100; ++i) {
>    start_updater(LockableRef<int>(values,values[i]);
> }
>
> i.e. LockableRef contains a reference to the mutex and one element of
> its "parent" Lockable<>, and presents the same interface as a data-full
> Lockable<>.

I think what you would want to do is just create one scoped lock, perhaps 
outside of the loop (a lock_acquirer in the lockable lib syntax) and use that 
to access the values in the array.  It could just pass an ordinary reference 
to the start_updater function, as long as start_updater doesn't keep any 
persistent copies of the reference around.

You do give me an idea though, I could make poet::monitor_ptr (pointer-like 
monitor) constructible from poet::monitor (value-like monitor) which would I 
think be similar to what you're getting at with LockableRef.  It would 
actually be very easy, since I implemented poet::monitor using monitor_ptr 
(out of laziness).

Incidentally, I find the example usage of lock acquirers in the 
thread_lockable examples a bit verbose and dangerous.  That is stuff like:

mbox::writelock_acquirer<mutexlockable_int> int_lock(*pLockableInt);
int& i = access_acquiree(int_lock);
i = 5;

Why not just support operator* (and operator-> for calling class methods) on 
the lock_acquirer class?  Then you could do something like:

mbox::writelock_acquirer<mutexlockable_int> int_lock(*pLockableInt);
*int_lock = 5;

Its less verbose, and by using the lock_acquirer directly it reduces the 
possibility of a dangling reference outliving the lock_acquirer it was 
obtained from.

- -- 
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH57+S5vihyNWuA4URAro/AKDJKYhHEjUCcPFW+tgv35Ak5NT87ACePs+F
sfW6gMAdgxWAoivYda2YL+M=
=ssSm
-----END PGP SIGNATURE-----