[concurrency-interest] НА: StampedLock: A possible SequenceLock replacement

Andriy Plokhotnyuk plokhotnyuk at gmail.com
Sat Jun 23 09:42:52 EDT 2012



Отправлено с моего коммуникатора HTC

----- Исходное сообщение -----
От: Doug Lea <dl at cs.oswego.edu>
Отправлено: 23 июня 2012 г. 16:17
Кому: Concurrency-interest at cs.oswego.edu <Concurrency-interest at cs.oswego.edu>
Тема: [concurrency-interest] StampedLock: A possible SequenceLock replacement


Early experience with jsr166e.SequenceLock suggests that it
might be less useful than anticipated. In addition to
concerns that correctly writing code using any seqlock-style
construct can be challenging, there are two technical issues
limiting its range of applicability:

1. Under high write rates, sequenced reads continually retry unless
readers fall back to getting the lock. But doing so causes other readers
to fail needlessly -- the lock is not actually protecting updates.
This tends to devolve into a very slow emulation of an ordinary lock,
and may do so under even relatively low write rates when there are
many readers. These could be avoided if some form of read-lock were
available for use on retry.

2. As Hans Boehm and others pointed out (including in a
paper at last week's MSPC workshop --
http://safari.ece.cmu.edu/MSPC2012/papers/p12-boehm.pdf),
SequenceLocks either require that all fields read be
volatile/final (which is the currently stated usage
restriction), or that the internal implementation of
sequence validation use some ordering mechanism not
expressible using current JMM rules. This second option
is possible (although not strictly explainable :-), but only
under a slightly different  API to encapsulate seq validation
as a method. This could in turn be supported via non-public
internal hotspot intrinsics (although some internal specs might
need to be strengthened to guarantee to do what they now do).

Attacking these issues presents an opportunity to also
address another continuing RFE -- providing a cheaper,
but more restricted, form of read-write lock
than our ReentrantReadWriteLock. (This includes
one in the upcoming paper by Jun Shirako et al
https://wiki.rice.edu/confluence/display/HABANERO/Publications)
Creating one that also allows optimistic reads would
further improve support for STM-like constructions.

One down side of schemes that can support seqlock-like
optimistic validated observations, plus read-locks, plus
write-locks is that the classes

[Включен не весь текст исходного сообщения]



More information about the Concurrency-interest mailing list