[concurrency-interest] Does StampedLock need a releaseFence in theory?

Hans Boehm boehm at acm.org
Fri Jul 15 14:06:36 EDT 2016


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?


On Fri, Jul 15, 2016 at 10:49 AM, Doug Lea <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.
>>
>
> Thanks.
>
> 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
> languages.
>
> -Doug
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160715/bed359a3/attachment.html>


More information about the Concurrency-interest mailing list