On Sep 9, 2005, at 5:32 AM, Ion Gaztañaga wrote:
http://home.twcny.rr.com/hinnant/cpp_extensions/threads_move.html
Do you have more information about these concepts and their use? It seems quite interesting for thread proposals.
The "performance testing" link off of the above page has example code: http://home.twcny.rr.com/hinnant/cpp_extensions/rw_perf.html
Currently in boost we have the following:
scoped_lock, scoped_try_lock, scoped_timed_lock
Right. And I went this route too (following boost's lead). But hindsight is 20/20. ;-) The scoped_lock, scoped_try_lock, and scoped_timed_lock concepts are all strict supersets of one another (and this is good). You can code a scoped_timed_lock, templated on the mutex type, and use it only as a scoped_lock with absolutely zero penalty. There is no extra data associated with a scoped_timed_lock over a scoped_lock. And the code associated with timed locking isn't instantiated unless you use it. Said another way, you can get rid of the template classes scoped_lock and scoped_try_lock, and rename scoped_timed_lock to scoped_lock, and then use this new "combined" scoped_lock for all three uses. You will pay no penalty in code size or speed, and you will cut your source code maintenance by a factor of 3. If you instantiate this new "combined" scoped_lock with a mutex that can not execute a timed_lock (for example), absolutely no harm is done ... unless of course the client of this instantiation actually tries to call timed_lock, in which case you would quite naturally get a compile time error. Analogy: std::vector doesn't require a default copy constructor of its contained type, unless you actually instantiate certain member functions of vector. My scoped_lock doesn't require the mutex to have a timed_lock() member unless you instantiate the timed_lock() member of the scoped_lock. So my scoped_lock is simply the boost scoped_lock, scoped_try_lock, scoped_timed_lock rolled into one class.
Your web talks about upgradeable, shareable, so maybe we could think about this when thinking about C++ threading interface.
The rw_perf.html page gives motivation for the read/write - renamed to scoped/sharable - and for adding the upgradable concept as well. The sharable and upgradable locks all meet your scoped/try/timed concepts, but do not demand these concepts of the mutex.
I suppose Kevlin Henney is thinking about this issues regarding its C++ Threading interface proposal, so maybe these concepts are interesting.
Alexander Terekhov's algorithm seems interesting, so we decide to go ahead with this, we should implement it on top of some boost atomic primitives.
<nod> See the performance link for a few notes on this (but there is no implementation posted there, only notes). -Howard