[concurrency-interest] Stupid Question

Vitaly Davidovich vitalyd at gmail.com
Tue Feb 12 17:01:46 EST 2013


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/20130212/edbc61ed/attachment-0001.html>


More information about the Concurrency-interest mailing list