4 ms·
what if you have a multi-threaded backend to the compiler that happens to lay down data in different orders?
by anth_anm 8y ago
what if you have a multi-threaded backend to the compiler that happens to lay down data in different orders?
- tantalor 8y agoThat's a bug. https://en.wikipedia.org/wiki/Race_condition https://en.wikipedia.org/wiki/Race_condition
- tedunangst 8y agoWhy is it a bug? I write a program to download four files. I do so in parallel. Sometimes X finishes first, sometimes Y finishes first, and the files are written to disk in a different order. Why do I want to serialize this operation?
- rbanffy 8y agoThe end result is a set of four files. You don't care about the order they are laid out on the disk and the next steps shouldn't let the order of those files influence the end result. Let's assume there is a latent bug in the compiler that gets triggered if file four is the first one. Good luck debugging that.
- anth_anm 8y agoIt's the internal structure of the files.
- tedunangst 8y agoBut parent claimed that creating a set with a different order was inherently a bug. Not that depending on the order of an unordered set was a bug.
- lixtra 8y agoWhy? Most compilers give no guarantees in which order they lay out the data. I love deterministic processes as much as everyone. But randomized approaches have their advantages too. And if a compiler has reasons to randomize output e.g. for speed than it’s a trade off to consider.
- anth_anm 8y agoThread finishes work grabs lock writes to file writes to index releases lock That's not a race condition. The output order doesn't matter, but it is nondeterministic.
- jabl 8y agoYou don't even need multi-threading. In gcc we had at least one case where a key=>value data structure was keyed by memory address, causing symbols to be emitted in different order depending on ASLR, phase of the moon, or whatever.