Comment by tialaramex | Hacker News Reader

Comment by tialaramex | Hacker News Reader

Parent Full thread

Interesting. As I understand it, this lands an approach in which Sequential Consistency is not guaranteed but if you have a data race you get even nicer guarantees than in Java and its authors believe this might be enough that real programmers working on real software can actually debug data races despite loss of sequential consistency.

In many popular languages today (e.g. C++) if you have a data race you're completely screwed, (e.g. the program exits successfully, even though it was supposed to loop forever serving TCP requests - good luck figuring out why). In Java they decided OK, that's not acceptable, so data races are constrained to only the data touched by the race and, importantly, that data is still legal it just might be astonishing (e.g. you were adding several small positive integers together from a shared data structure in parallel, but due to a misunderstanding in your design this was actually a data race, and some time later somehow your total is now zero, but you won't crash or whatever)

OCaml intends to further constrain the consequences in time, if the total was 114 when you stopped adding, it will still be 114 later, it won't mysteriously become zero (or any other value) thanks to a data race which must have happened before you checked.

[I'm sure I have some details wrong, but this is the gist]

What remains to be seen is: Is that enough? There was great hope when Java made its rules that they were enough and programmers could understand what was wrong in a Java program with data races, that did not pan out as I understand it. So, it seems to me that it's possible OCaml ends up in the same situation.

> e.g. you were adding several small positive integers together from a shared data structure in parallel, but due to a misunderstanding in your design this was actually a data race, and some time later somehow your total is now zero

Could you clarify why/how this would happen? Is it because the last process sets it to zero to initialize a variable?

I can’t conceptualize the steps that would end up with this result if all processes are adding. It seems like it would at least equal the result of the final thread’s calculation.

Non aligned data structures being written to. E.g. if you're adding 2 nibbles and writing it to the first part of a byte or writing a byte on a packed struct.

I believe the less scary race in Java implies a lower performance upper bound. Does the nicer guarantees in multicore OCaml have the same drawback? I.e. even less than Java?

(co-author of the OCaml memory model paper here)

The details of the 'LDRF' (local data race freedom) property are described in detail here: https://anil.recoil.org/papers/2018-pldi-memorymodel.pdf

The performance numbers are in the paper abstract: "our evaluation demonstrates that it is possible to balance a comprehensible memory model with a reasonable (no overhead on x86, ~0.6% on ARM) sequential performance trade-off in a mainstream programming language". It's a little higher on PowerPC but still very usable, and RISC-V overheads should be roughly comparable to ARM.

As the paper clarifies, this is for the performance of non-atomic read/writes in sequential setting. The paper left the performance evaluation for atomic read/writes to future work. Is there any indication yet regarding the performance in a parallel setting compared to weaker guarantees?

That's right -- we first wanted to establish that existing OCaml code wouldn't be adversely impacted. There are various efforts ongoing to build interested (locked and lock-free) concurrent data structures, so that will inform the parallel performance results. Nothing published yet.

Does this feature inhibit any kind of optimization that current compilers could perform?

According to the paper “any compiler optimisation that breaks the load-to-store ordering is disallowed.”

If you use Atomic* classes and the available concurrent standard lib datastructures, Java concurrency should not be an issue to any non-junior developer.

Reply on news.ycombinator.com