[concurrency-interest] jdk9 VarHandle and Fence methods

Hans Boehm boehm at acm.org
Mon Sep 14 20:44:55 EDT 2015

FWIW, this general issues is discussed in section 3 of
http://dl.acm.org/citation.cfm?id=1375581.1375591 .

Yet another argument against providing the stronger guarantees is that, on
many architectures, it doesn't just slow down trylock(), it more
importantly slows down lock().  In general, if your code cares about
ordering for unsuccessful trylock(), then it's not robust against, say, a
debugging thread unexpectedly acquiring the lock for a short period.  In my
view, in such a case, you're no longer using it as a lock, and you should
be using something else, e.g. an atomic object, with stronger guarantees.

On Fri, Sep 4, 2015 at 4:18 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 09/03/2015 02:19 PM, Oleksandr Otenko wrote:
>> Has anyone come up with the answer about ordering for tryLock, or have I
>> missed it?
> You missed the dog not barking :-)
> The Lock specs don't require any specific HB effects here on failed
> tryLock. Even if we wanted to, we cannot retroactively impose any
> considering that anyone can implement the Lock interface (not just j.u.c)
> and some of these might become in violation.
> As you and Vitaly pointed out, there are a few fringe cases where
> users might want to impose ordering on failure. In jdk9, you'll
> me able to do this with moded VarHandle accesses and/or fences. The
> resulting extra fencing might be redundant here and there, but if you
> cared enough, you could create and rely on custom locks with stronger
> guarantees.
> -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/20150914/ad8ece65/attachment.html>

More information about the Concurrency-interest mailing list