4 ms·
Not all race conditions are as complex as you make them to be, in particular if they are done on purpose. And many race conditions don't have anything to do wi
by jfkebwjsbx 6y ago
Not all race conditions are as complex as you make them to be, in particular if they are done on purpose.
And many race conditions don't have anything to do with the memory model or compiler optimizations.
- MaxBarraclough 6y 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 6y ago[deleted]
- throwaway2048 6y agoIf R2 returns before R1 that is still a race condition, but it might not be a bug.
- MaxBarraclough 6y 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 6y agoThere is even Promise.race provided for that purpose in JavaScript. You can typically use it to implement a watchdog.
- AnimalMuppet 6y agoParticularly if they are done on purpose??? Can you give an example of when one would (sanely) want to create a race condition?
- chrisseaton 6y agoI don’t think you ever want a race condition for the sake of it but there are many daily cases where you don’t care that it races and fixing it would have terrible downsides. In a distributed system they’re practically unavoidable I think!