[concurrency-interest] jdk9 VarHandle and Fence methods

Vitaly Davidovich 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
>> guarantees.
>>
>> -Doug
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>
> _______________________________________________
> 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/e880872b/attachment.html>


More information about the Concurrency-interest mailing list