[concurrency-interest] Stupid Question

Stanimir Simeonoff stanimir at riflexo.com
Tue Feb 12 16:43:36 EST 2013


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/8fd202ba/attachment.html>


More information about the Concurrency-interest mailing list