[concurrency-interest] implementing reentrant locks with Thread.currentThread

Vitaly Davidovich vitalyd at gmail.com
Fri Nov 22 16:14:46 EST 2013

Getting current thread is typically optimized on most VMs and runtime libs,
and they all do it very similarly (stashing reference to the object in TLS).

As for hotspot, are you sure your tests were done on calls to
Thread.currentThread inside methods that were JIT'd? How do you know that
it's getting the current thread that was slow?


Sent from my phone
On Nov 22, 2013 11:17 AM, "Sanne Grinovero" <sanne.grinovero at gmail.com>

> Hi Andrew,
> that comment was very interesting as it doesn't match with what we
> have observed by sampling on relatively complex applications.
> Could you confirm that it would be similar to a field access even on
> OpenJDK / x86-64 ?
> Could this be a particularly suited instruction to have the current
> thread de-scheduled? The systems on which I observed this have often
> way too many threads than what I'd like them to have (given the amount
> of real cores), so I expect to always have many threads parked, that
> would affect our sampling information.
> Currently the idea we've got from the diagnostics - by looking at
> sampling only so far - is that we should try avoiding some invocations
> to Thread.currentThread().
> Sanne
> On 8 November 2013 17:08, Andrew Haley <aph at redhat.com> wrote:
> > On 10/21/2013 04:21 AM, Andy Nuss wrote:
> >
> >> I was wondering, if one is building a type of re-entrant lock, do
> >> you get better performance by paying the cost of
> >> Thread.currentThread() for each lock operation, or using a
> >> ThreadLocal variable.  If one chooses the latter, is there an impact
> >> by having lots of effective thread local storage bloat?
> >
> > In addition to David Holmes' response, you may be interested to know
> > just how littel overhead Thread.currentThread() actually is.  On a
> > modern RISC, it is exactly
> >
> >        ldr      x13, [xthread,#480]
> >
> > i.e. the cost of Thread.currentThread() is the same as that of a field
> > access.  A ThreadLocal variable is considerably more expensive.
> >
> > Andrew.
> > _______________________________________________
> > 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/20131122/f01d673b/attachment.html>

More information about the Concurrency-interest mailing list