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

Sanne Grinovero sanne.grinovero at gmail.com
Fri Nov 22 11:11:06 EST 2013


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


More information about the Concurrency-interest mailing list