Toward generic atomic operations
Toward generic atomic operations
Posted Aug 7, 2012 14:18 UTC (Tue) by sdalley (subscriber, #18550)Parent article: Toward generic atomic operations
Why do we need the last bit? Surely you don't want to invalidate reservations willy-nilly - the pre-empting task may have nothing to do with the one being pre-empted and therefore be no danger to it. Maybe a task kicked off by unrelated network activity, etc, etc. If it is actually contending, it will also be attempting a reservation and will fail/loop at that point anyway?The first instruction, often called load-with-reservation, load-exclusive, or load-link, atomically loads the value of a given memory location into a register and marks that memory location as reserved.
The loaded value can then be manipulated arbitrarily before a second instruction, often called store-exclusive, or store-conditional, atomically stores an updated value from a register back to a given memory location, provided that no modification has been made to that memory location in the interim.
...In every case, outstanding reservations are invalidated upon a context switch between running tasks (often as a result of a specific invalidation in the context-switch code)....
Posted Aug 8, 2012 9:18 UTC (Wed)
by mpr22 (subscriber, #60784)
[Link]
ISTR running into a problem where store-conditional appeared to be behaving as "store if there is a currently valid reservation" rather than the desired "store if the destination address is the target of the currently valid reservation".
Toward generic atomic operations