3 ms·
I think that according to standard terminology, syncing accesses to mutable data does prevent all data races - but not all race conditions: http://blog.regehr.o
by _yosefk 13y ago
I think that according to standard terminology, syncing accesses to mutable data does prevent all data races - but not all race conditions: http://blog.regehr.org/archives/490 http://blog.regehr.org/archives/490 (Race Conditions vs Data Races)
The nice thing about eliminating queue-like interfaces - and locks, STM, message passing, lock-free containers etc. are actually a form of a queue-like interface - is that it eliminates all race conditions which aren't data races. Then you can have automated debugging tools find said data races.
Unfortunately, this doesn't work with event handling systems, because they're often required to have queue semantics to resolve inevitable conflicts between requests.
- fmstephe 13y agoCan you give an example of a system where queue-like interfaces have been removed but data races still exist. I feel that there are some important, and interesting, details I am not grasping.
- _yosefk 13y agoSure; a parallel for loop with each task processing a[0], a[1], ... a[N] has no data races but if task 0 modifies a[0] and reads a[1], task 1 modifies a[1] and reads a[2], etc. then this loop is full of data races without there being anything queue-like (that is, you never say "I'll do this thing here unless someone beats me to it in which case I will let them finish first.")
- fmstephe 13y agoThanks