"Chris M. Thomasson" <cristom@charter.net> writes:
I was wondering if the following invention of mine might be of use to Boost:
http://software.intel.com/en-us/forums/intel-threading-building-blocks/topic... (please __read_all__; thank you)
It certainly looks interesting. The current boost::shared_mutex implementation is rather heavyweight due to timed lock support. I see that you've submitted it to TBB. Are you still in a position to submit to Boost, or do you have to assign copyright to Intel? In terms of scheduling I see that if the mutex is locked for writing then waiting readers will take precedence over waiting writers, whilst when it is locked for reading then a waiting writer will block further readers, and the writer will take precedence. This puts the mutex in control of the scheduling, and does not allow the OS to select which thread to wake based on priorities. For example, if a writer holds the lock, and one of the waiting readers is low priority then it is given the lock when the writer unlocks, even if there is a high priority writer waiting. The high priority writer is then blocked until the low priority reader has completed its task. Whether or not that's a good thing is open for discussion. I also note that there are no "try_wrlock()" or "try_rdlock()" functions. For integration with boost, it would be good if the write-lock member functions could be called "lock()" and "unlock()", whilst the read-lock member functions are called "lock_shared()" and "unlock_shared()". This would allow the existing RAII classes to be used with this new rwmutex type. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976