Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Are you sure it's complete code? I don't see where you're creating threads or where BuildKCData is being called from.</p> <p>You ought to have a memory barrier after pthread_kill(), even though I doubt it makes a difference in this case.</p> <p><strong>EDIT:</strong> You're confusing in-order execution and cache-consistency.</p> <p><strong>Cache consistency:</strong> x86 (currently) guarantees that aligned 4-byte accesses are atomic, so <code>a[0]=123</code> in thread A and <code>a[1]=456</code> in thread B will work — thread C will eventually see "123,456". There are various cache-consistency protocols around, but I believe it's approximately a MRSW lock.</p> <p><strong>Out-of-order execution:</strong> x86 doesn't guarantee ordering of reads (and possibly writes; there was a debate about whether sfence was needed in the linux kernel). This lets the CPU prefetch data more effectively, but it means <code>a[0]=123,a[1]</code> in thread A and <code>a[1]=456,a[0]</code> in thread B could both return 0, because the fetch of a[1] can happen before the load of a[0]. There are two general ways to fix this:</p> <ul> <li>Only access shared data when you're holding the lock. In particular, do not read shared data outside of the lock. Whether this means a lock for each entry or a lock for the entire array is up to you, and what you think lock contention is likely to be like (tip: it's not usually very big).</li> <li>Stick a memory barrier between things that need to be in order. This is difficult to get right (pthread doesn't even have memory barriers; <code>pthread_barrier</code> more like a sync point).</li> </ul> <p>While memory barriers are a recent trend, locking is <em>far</em> easier to get right (<em>I am holding the lock, therefore nobody else is allowed to change the data under my feet</em>). Memory barriers are all the rage in some circles, but there's a lot more to get right (<em>I hope this read is atomic</em>, <em>I hope other threads write atomically</em>, <em>I hope other threads use a barrier</em>, and <em>oh yeah, I need to use a barrier too</em>).</p> <p>And if locking's too slow, reducing contention will be much more effective than replacing locks with barriers and hoping you got it right.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload