4 ms·
> And many race conditions don't have anything to do with the memory model or compiler optimizations. For example, poorly structured response-handlers in JavaS
by MaxBarraclough 7y ago
> And many race conditions don't have anything to do with the memory model or compiler optimizations.
For example, poorly structured response-handlers in JavaScript. If the code assumes that request R1 always returns before request R2, things may misbehave if that assumption is violated. That's a race condition, but as you say, it's nothing to do with memory models or compiler trickery, as JavaScript gives you just the one thread (not counting workers).
- deleted 7y ago[deleted]
- throwaway2048 7y agoIf R2 returns before R1 that is still a race condition, but it might not be a bug.
- MaxBarraclough 7y ago> If R2 returns before R1 that is still a race condition That's not correct. Look at chrisseaton's definition. If the observable program behaviour doesn't change depending on the order in which the requests complete, there's no race condition. (In JavaScript this might be done with Promise.all.) You're right that not all race conditions are bugs.
- gildas 7y agoThere is even Promise.race provided for that purpose in JavaScript. You can typically use it to implement a watchdog.