How to trigger races reliably in the Linux kernel

Re:How to trigger races reliably in the Linux kernel by MaxBarraclough on Tuesday May 05, 2020 @10:01AM (#23080086)

> 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).

[ Parent | on HN ]

Re:How to trigger races reliably in the Linux kernel by throwaway2048 on Tuesday May 05, 2020 @11:26AM (#23081033)

If R2 returns before R1 that is still a race condition, but it might not be a bug.

[ Parent | on HN ]

Re:How to trigger races reliably in the Linux kernel by MaxBarraclough on Tuesday May 05, 2020 @11:43AM (#23081244)

> 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.

[ Parent | on HN ]

Re:How to trigger races reliably in the Linux kernel by gildas on Tuesday May 05, 2020 @12:27PM (#23081778)

There is even Promise.race provided for that purpose in JavaScript. You can typically use it to implement a watchdog.

[ Parent | on HN ]