Solving hard locks shouldn't be encouraged.


It shouldn't be encouraged to allow this read write locker to solves hard locking situations. It may make things thread safe. But it defeats the purpose of having code run in parallel.
As such, an optional parameter in the constructor should be introduced which would cause 1.) an assertion in debug mode, 2.) throw an exception, 3.) nothing, or 4.) a hard lock (removing the hard-lock prevention overhead) to happen. This way, performance bottle necks caused where hard locks would otherwise happen can be assessed and corrected. And very little code changes would need to be made once stability is guaranteed with hard locks being allowed to occur.
A feature could be extended from this issue which would allow this locker to profile how locking occurs and where bottlenecks might happen.
Closed Sep 22, 2010 at 2:49 PM by TamusJRoyce
Parameter available in constructor to allow users to detect and remove hard locks. Same parameter can be changed to remove overhead and allow hard locks.