[concurrency-interest] Stupid Question

Vitaly Davidovich vitalyd at gmail.com
Tue Feb 12 16:37:38 EST 2013

Do you mean false sharing due to the lock word sitting on same cache line
as the lock object itself? 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/6f79222f/attachment-0001.html>

More information about the Concurrency-interest mailing list