3 ms·
Strictly speaking you're right. However it's not necessary that other cores see the new store immediately: it's only necessary that they see it before the memor
by ridiculous_fish 11y ago
Strictly speaking you're right. However it's not necessary that other cores see the new store immediately: it's only necessary that they see it before the memory is freed, which occurs after a substantial delay sufficient to prevent these out-of-order issues on other CPUs. This is the technique by which memory barriers are elided on the read side (but not the write side).
- vitalyd 11y agoThis is both clever and terrifying :). How do they prevent compiler from scheduling the load early, observing, and using the stale cache pointer? Do they have at least a compiler fence on the read side?
- ridiculous_fish 11y agoNothing prevents using a stale cache pointer. The stale cache still contains correct data, so using it is benign, up until it gets deallocated. A stale cache pointer may become wrong if a method implementation is replaced, e.g. by a category, but replacing a method while calling it in another thread is inherently racey.
- vitalyd 11y agoBy stale I meant holding a ref to a cache about to be deleted.
- bdonlan 11y agoThe read-side code in question is hand-written assembly code, isn't it? And on the hardware side, observing pc will probably result in an actual memory barrier happening anyway (even if no signal is sent internally the kernel must still suspend the thread to capture register state, and then it needs a barrier to communicate that result back to the asking thread).
- vitalyd 11y agoYes, perhaps that part is in the hand written assembly portion that's mentioned.
- asveikau 11y agoYes, you kind of do need the read barrier, otherwise you get exactly the problem I described with the stale cache. You can't "kinda" have synchronization just as a design for a mutex can't be a "kinda" lock... You may get away with it for a while, but like I said, playing with fire.