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.