[cpp-threads] D2335 (sequential consistency proof) revision

[Paul E. McKenney]

On Sat, Aug 25, 2007 at 12:36:40PM -0400, Doug Lea wrote:
> Lawrence Crowl wrote:
> > 
> >>
> >> We allow trylock and timedlock to fail spuriously, even if the lock was
> >> never held.
> > 
> > Specifically, trylock may return "I did not lock" even though the
> > lock was free.  (Spuriously locking when the lock was not free
> > would be ... bad.)
> > 
> 
> Notice though that the concept of a lock being free is itself
> different across different kinds of locks.
> 
> Inside lock implementations, you sometimes have a choice
> about whether you want to allow a given tryLock to succeed.
> For example, with pure FIFO/fair locks, you might decide to return
> false from tryLock if the lock is momentarily free but some other
> thread should get it first. Digressing a little:
> We don't actually do this in Java ReentrantLock etc. We debated it.
> Either way is a bit arbitrary, but specifically exempting
> tryLock from fairness rules seems slightly preferable, so that's
> what we do, and document.

And on NUMA-aware queued locks, you might condition the decision on
whether or not the lock is currently on your NUMA node.  And of course
on the fairness conditions used to avoid starving other nodes.

Some them would have provided ordering on failure, but I no longer
have access to the relevant source code, so cannot take a census.
(None in Linux at this point, as recent hardware no longer favors
NUMA-aware locking for the most part.)

						Thanx, Paul

> A better case in point is read-write locks, where tryLock will fail
> or succeed according to reader/writer/FIFO preference criteria.
> 
> These sorts of considerations led us to explicitly not require memory
> effects for failed tryLocks. Pasting from java.util.concurrent.locks.Lock:
> 
> 
> "All Lock implementations must enforce the same memory synchronization semantics 
> as provided by the built-in monitor lock, as described in  The Java Language 
> Specification, Third Edition (17.4 Memory Model):
> 
>      * A successful lock operation has the same memory synchronization effects 
> as a successful Lock action.
>      * A successful unlock operation has the same memory synchronization effects 
> as a successful Unlock action.
> 
> Unsuccessful locking and unlocking operations, and reentrant locking/unlocking 
> operations, do not require any memory synchronization effects."
> 
> -Doug
> 
> 
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads