Boost logo

Boost :

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

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

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

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at