[concurrency-interest] StampedLock Article
dl at cs.oswego.edu
Tue Dec 3 07:29:11 EST 2013
On 12/02/2013 09:31 PM, Vitaly Davidovich wrote:
> Right, it's a bit unclear on what a good case for this lock is. I'm guessing
> the advantage is if you use the optimistic version - that avoids any expensive
> stores and doesn't block writers - for tiny read code sections on locks that are
> read-mostly. Otherwise, seems like it may not perform all that well (e.g.
> validate() missing in cache because another core wrote to the lock in the meantime).
> Builtin synchronizer (I.e synchronized keyword) for small/cheap code sections
> that don't contend seems decent enough. Biased locking + (adaptive) spinning
> should, in theory, be good enough for these cases.
Please measure. Sometimes biased locking is fine, sometimes much less
than fine. As a rule of thumb, if you expect contention not to be rare,
consider using a j.u.c Lock. And unless you need reentrancy, StampedLock
is often the best choice of these in terms of performance and features.
I expect that Heinz's future installments will spell some of this out
for many use cases, but ... please measure.
> Also, one other thing synchronized has going for it is it handles async aborts
> of threads (I.e. thread.stop()). I know stop() is deprecated and all, but you
> never know.
But you do know! As of JDK8, Thread.stop is really gone.
It is the first deprecated method to have actually been
de-implemented. It now just throws UnsupportedOperationException.
More information about the Concurrency-interest