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

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-03-23 18:47:43

klaus triendl wrote:
> Please have a look at my code, it can be found in the boost vault, name 
> "thread_lockable.zip".

Hi Klaus,

I finally got around to looking at this.  Yes, it does what I expect it to.

One detail I noticed was that you make the mutex mutable, so that you 
can lock a const object.  This is something that I have worried about, 
because I fear that there are "gotchas".  Do any experts have opinions 
about this?

I said before that I found my own locking pointer (or locking 
reference) was more verbose than explicitly locking the mutex and 
accessing the data, and so have not used it much.  I've now remembered 
another practical problem with it.  Here's the code without Lockable<>:

void start_updater(mutex& m, int& val)
{
   // spawn a thread that periodically locks m and changes val
}

mutex m;
array<int,100> values;

for (int i=0; i<100; ++i) {
   start_updater(m,values[i]);
}

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

But because Lockable and LockableRef aren't actually the same type, I 
can't write

void start_updater(Lockable<int> i);

and use it with both.

Is this something that you have thought about?

Phil.