[concurrency-interest] jdk9 VarHandle and Fence methods
vitalyd at gmail.com
Mon Sep 14 21:41:22 EDT 2015
How does it slow down lock()?
I don't necessarily disagree but I can certainly see people considering
tryLock to have same ordering effect as (failed) CAS. It's certainly true
that a CAS is a lower level primitive than a lock, but I don't know if that
resonates immediately when thinking about this. It's also the case that on
very popular platforms such as x86 a failing tryLock will have the same
ordering as a successful one, and no difference is observed (and JIT
doesn't do anything different).
I don't understand the debugger thread example - what's the issue there?
sent from my phone
On Sep 14, 2015 9:07 PM, "Hans Boehm" <boehm at acm.org> wrote:
> 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
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest