[concurrency-interest] Stupid Question

Stanimir Simeonoff stanimir at riflexo.com
Tue Feb 12 17:07:07 EST 2013


I am not sure I understand why the ReentrantLock.sync field should be on
the same cache line as ABQ.lock field, it's possible but not necessary true.

Stanimir

On Wed, Feb 13, 2013 at 12:01 AM, Vitaly Davidovich <vitalyd at gmail.com>wrote:

> Wow OK, that's very paranoid :).  Moving the address into a register
> doesn't help though as I mentioned earlier; only scalar loads would benefit
> from this.
>
> Sent from my phone
> On Feb 12, 2013 4:43 PM, "Stanimir Simeonoff" <stanimir at riflexo.com>
> wrote:
>
>> On Tue, Feb 12, 2013 at 11:37 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:
>>
>>> Do you mean false sharing due to the lock word sitting on same cache
>>> line as the lock object itself?
>>>
>> Nope, just the ArrayBlockingQueue.lock being on the same cache line as
>> any other object. Changing "an int" field on that object would invalidate
>> the cache line holding the lock.
>>
>> Stanimir
>>
>>
>>> Sure, but storing a pointer in a register is not going to help since
>>> ultimately you have to fetch the value from memory address that's stored in
>>> the register (some offset from that to find the lock word), and if cache
>>> line is gone, you get hit anyway.  In other words, you have to deref the
>>> value in the register - it's not storing a scalar value.  Or did I
>>> misunderstand your point?
>>>
>>> Sent from my phone
>>> On Feb 12, 2013 4:22 PM, "Stanimir Simeonoff" <stanimir at riflexo.com>
>>> wrote:
>>>
>>>> This should be in some register (ECX on 32bit x86) and of course it
>>>> still has to deref./load 'lock'. Calling the method may not need to
>>>> derefence this.
>>>> However the 2nd load could be avoided (and possible false sharing
>>>> prevented) if the value is stored on the stack/kept in register. The
>>>> current method body is too short to actually worry about since there would
>>>> be likely enough registers available. Yet, the idiom is used everywhere, so
>>>> the current case just follows suits.
>>>>
>>>> Stanimir
>>>>
>>>> On Tue, Feb 12, 2013 at 11:10 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:
>>>>
>>>>> I don't think it's that since "this" is already loaded (or else you
>>>>> can't call the method).  I believe Doug did this because he found that
>>>>> final field loads weren't commoned across lock() calls (even though they
>>>>> could be).
>>>>>
>>>>> Sent from my phone
>>>>> On Feb 12, 2013 4:04 PM, "Nathan Reynolds" <nathan.reynolds at oracle.com>
>>>>> wrote:
>>>>>
>>>>>>  this.lock is a memory indirection (i.e. dereferences "this" to get
>>>>>> the value in "lock") and could incur a cache miss (i.e. loads
>>>>>> ArrayBlockQueue into the L1 cache) or even worse false sharing.  By copying
>>>>>> to the local variable, the value is on the stack.  There won't be any
>>>>>> memory indirection to access the value.  Cache misses would only happen if
>>>>>> the thread context switched.  False sharing is impossible.
>>>>>>
>>>>>> Nathan Reynolds<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>| Architect |
>>>>>> 602.333.9091
>>>>>> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server
>>>>>> Technology
>>>>>>  On 2/12/2013 1:41 PM, javamann at cox.net wrote:
>>>>>>
>>>>>> Stupid question time. While going through the code for an ArrayBlockQueue I came across numerous instances where the instance 'lock' is copied to a variable in a Method. I know there is a reason for this, I just don't know what it is.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -Pete
>>>>>>
>>>>>>     public int remainingCapacity() {
>>>>>>         final ReentrantLock lock = this.lock;
>>>>>>         lock.lock();
>>>>>>         try {
>>>>>>             return items.length - count;
>>>>>>         } finally {
>>>>>>             lock.unlock();
>>>>>>         }
>>>>>>     }
>>>>>>
>>>>>> _______________________________________________
>>>>>> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://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
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 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/20130213/5f9156c8/attachment.html>


More information about the Concurrency-interest mailing list