<div dir="ltr"><div>> <span style="font-size:12.8000001907349px">How does it slow down lock()?</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">It depends on the precise guarantee you provide, and I suspect this thread didn't quite agree on that.  The most natural one is that the succeeding lock acquisition happens before the failed trylock().  That implies that if we have</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">x = 1;</span></div><div><span style="font-size:12.8000001907349px">lock();</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">those can't be reordered by the hardware, since a failing trylock() would have to see the assignment to x.  That requires a fence between them on ARM or Power.</span></div><div><br></div>I think the right way to think of trylock(), at least informally, is as allowing spurious failures. I.e. trylock() is allowed to behave as though the lock was held when it isn't.  You thus can't conclude anything about other threads from the fact that it failed.  In this view you don't have to think about memory ordering issues when reasoning about correctness, you just reason about spurious failures instead.<div><br></div><div>If your code is robust against unknown, e.g. debugger, threads acquiring the lock now and then, then it must be robust against this sort of spurious failure.  If the lock is really used only to provide mutual exclusion, this should not affect correctness.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 14, 2015 at 6:41 PM, Vitaly Davidovich <span dir="ltr"><<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">How does it slow down lock()?</p>
<p dir="ltr">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).</p>
<p dir="ltr">I don't understand the debugger thread example - what's the issue there?</p>
<p dir="ltr">sent from my phone</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Sep 14, 2015 9:07 PM, "Hans Boehm" <<a href="mailto:boehm@acm.org" target="_blank">boehm@acm.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">FWIW, this general issues is discussed in section 3 of <a href="http://dl.acm.org/citation.cfm?id=1375581.1375591" target="_blank">http://dl.acm.org/citation.cfm?id=1375581.1375591</a> .<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 4, 2015 at 4:18 AM, Doug Lea <span dir="ltr"><<a href="mailto:dl@cs.oswego.edu" target="_blank">dl@cs.oswego.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 09/03/2015 02:19 PM, Oleksandr Otenko wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Has anyone come up with the answer about ordering for tryLock, or have I missed it?<br>
</blockquote>
<br></span>
You missed the dog not barking :-)<br>
<br>
The Lock specs don't require any specific HB effects here on failed<br>
tryLock. Even if we wanted to, we cannot retroactively impose any<br>
considering that anyone can implement the Lock interface (not just j.u.c)<br>
and some of these might become in violation.<br>
<br>
As you and Vitaly pointed out, there are a few fringe cases where<br>
users might want to impose ordering on failure. In jdk9, you'll<br>
me able to do this with moded VarHandle accesses and/or fences. The<br>
resulting extra fencing might be redundant here and there, but if you<br>
cared enough, you could create and rely on custom locks with stronger<br>
guarantees.<span><font color="#888888"><br>
<br>
-Doug</font></span><div><div><br>
<br>
_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel="noreferrer" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel="noreferrer" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
<br></blockquote></div>
</div></div></blockquote></div><br></div>