[concurrency-interest] Stupid Question

Nathan Reynolds nathan.reynolds at oracle.com
Tue Feb 12 17:24:12 EST 2013


In one case where I hit false sharing, it was because 2 (C++) objects 
were next to each other and both were updated very frequently.  All I 
had to do is move them to their separate corners and they behaved much 
better.  :)

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 3:07 PM, Stanimir Simeonoff wrote:
> 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 
> <mailto: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 <mailto:stanimir at riflexo.com>> wrote:
>
>         On Tue, Feb 12, 2013 at 11:37 PM, Vitaly Davidovich
>         <vitalyd at gmail.com <mailto: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 <mailto: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 <mailto: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
>                     <mailto: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 <tel:602.333.9091>
>                         Oracle PSR Engineering
>                         <http://psr.us.oracle.com/> | Server Technology
>                         On 2/12/2013 1:41 PM, javamann at cox.net
>                         <mailto: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 list
>>                         Concurrency-interest at cs.oswego.edu  <mailto:Concurrency-interest at cs.oswego.edu>
>>                         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>                         _______________________________________________
>                         Concurrency-interest mailing list
>                         Concurrency-interest at cs.oswego.edu
>                         <mailto:Concurrency-interest at cs.oswego.edu>
>                         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>                     _______________________________________________
>                     Concurrency-interest mailing list
>                     Concurrency-interest at cs.oswego.edu
>                     <mailto: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/e884f1f0/attachment-0001.html>


More information about the Concurrency-interest mailing list