Author sbt
Recipients Sebastian.Noack, asvetlov, jyasskin, kristjan.jonsson, mklauber, pitrou, sbt
Date 2012-10-01.12:16:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1349093795.94.0.845842594576.issue8800@psf.upfronthosting.co.za>
In-reply-to
Content
I think Sebastian's algorithm does not correctly deal with the non-blocking case.  Consider the following situation:

* Thread-1 successfully acquires exclusive lock.
  Now num_got_lock == 1.

* Thread-2 blocks waiting for shared lock.
  Will block until (num_got_lock == 1 and excl_count == 0).
  Now num_got_lock == 1.

* Thread-3 does non-blocking acquire of shared lock but fails.
  Now num_got_lock == 2.

Now, since num_got_lock == 2, the predicate that Thread-2 is waiting for will not happen until num_got_lock overflows.

This is probably fixable if we just prevent a failed non-blocking acquire from modifying num_acq_lock and num_got_lock.  (But I don't see how to extend the algorithm to allow timeouts.)
History
Date User Action Args
2012-10-01 12:16:35sbtsetrecipients: + sbt, pitrou, kristjan.jonsson, jyasskin, asvetlov, mklauber, Sebastian.Noack
2012-10-01 12:16:35sbtsetmessageid: <1349093795.94.0.845842594576.issue8800@psf.upfronthosting.co.za>
2012-10-01 12:16:35sbtlinkissue8800 messages
2012-10-01 12:16:35sbtcreate