[concurrency-interest] Does StampedLock need a releaseFence in theory?
dl at cs.oswego.edu
Fri Jul 15 14:52:55 EDT 2016
On 07/15/2016 02:06 PM, Hans Boehm wrote:
> My impression is that Linux kernel seqlock use cases don't care about write
> performance. Presumably you have some StampedLock clients in mind here that do
> care, because they don't know the reader-writer mix ahead of time? If writers
> are known to be frequent, this doesn't seem like the right tool?
StampedLock is multimodal. In the recommended usages (for example
those listed in javadocs), users switch from optimistic to ReadLock on
In any case, I mainly had in mind possible impact on other
versioned STM-ish locks out there with optimistic modes.
> On Fri, Jul 15, 2016 at 10:49 AM, Doug Lea <dl at cs.oswego.edu
> <mailto:dl at cs.oswego.edu>> wrote:
> On 07/15/2016 10:27 AM, Will Deacon wrote:
> a fence would be required to maintain order with a subsequent store.
> I now agree with Martin that we should add VarHandle.storeStoreFence
> to write-unlock.
> Backing up: We've long known that versioned locks (seqlocks, StampedLock)
> should not in general allow "roach-motel" reorderings. We couldn't
> introduce StampedLock until we had fence intrinsics for the load-load
> case. But no one considered that the implementation of write-unlock
> via CAS might permit hardware write reorderings. Thanks to the ARM
> folks for finding the tiny bit of wiggle room in CAS specs that
> might in theory (if not in practice) require the complementary
> fence on unlock. Too bad this will slow down some implementations
> for no good reason, but probably not noticeably. I wonder if/how
> this impacts other versioned lock implementations in other
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
More information about the Concurrency-interest