3 ms·

Why do we need this? The following code "works": http://move.rupy.se/file/atomic.txt http://move.rupy.se/file/atomic.txt

by bullen 6y ago

scott_s 6y ago
First sentence: > LOMP, short for Little OpenMP (runtime), is a small OpenMP runtime implementation that can be used for educational or prototyping purposes.
jcranmer 6y ago
That code actually doesn't work, but it's written in such a way that it's impossible to tell when it doesn't work. Data races in C/C++ code are undefined behavior, which means you get 0 theoretical guarantees as to what will actually happen. But I'm guessing you don't care about theory, but practice. In actual practice, compilers can (and do!) move around loads and stores--these are expensive, and eliminating them were possible is almost always insanely profitable. In this specific example, there isn't really any optimization that is likely to screw you up. However, the hardware can screw you up here. There's no guarantee that the stores arrive in any particular order, and no guarantee that temporally later reads will actually see the results of temporally earlier writes. You need various kinds of synchronizations (and atomic read-modify-write operations) to actually develop multithreaded code properly. But your example doesn't have any, and since it's literally just reading and writing random values, there's no way of telling if the semantics you think it is is actually the semantics it actually is just by running it: you can't find any failure modes where hardware turns out to violate sequential consistency.
- bullen 6y ago
  Ok, obviously I will handle the race conditions. The point is if you can write joint parallel code with atomic variables why bother with OO?
  - scott_s 6y ago
    OpenMP is not object-oriented. It is the correct version of what you alluded to, with 24 years of meeting the needs of the high-performance computing community.

Why do we need this? The following code "works": http://move.rupy.se/file/atomic.txt http://move.rupy.se/file/atomic.txt

by bullen 6y ago

Why do we need this? The following code "works": http://move.rupy.se/file/atomic.txt http://move.rupy.se/file/atomic.txt

scott_s 6y ago

First sentence: > LOMP, short for Little OpenMP (runtime), is a small OpenMP runtime implementation that can be used for educational or prototyping purposes.

jcranmer 6y ago

That code actually doesn't work, but it's written in such a way that it's impossible to tell when it doesn't work. Data races in C/C++ code are undefined behavior, which means you get 0 theoretical guarantees as to what will actually happen. But I'm guessing you don't care about theory, but practice. In actual practice, compilers can (and do!) move around loads and stores--these are expensive, and eliminating them were possible is almost always insanely profitable. In this specific example, there isn't really any optimization that is likely to screw you up. However, the hardware can screw you up here. There's no guarantee that the stores arrive in any particular order, and no guarantee that temporally later reads will actually see the results of temporally earlier writes. You need various kinds of synchronizations (and atomic read-modify-write operations) to actually develop multithreaded code properly. But your example doesn't have any, and since it's literally just reading and writing random values, there's no way of telling if the semantics you think it is is actually the semantics it actually is just by running it: you can't find any failure modes where hardware turns out to violate sequential consistency.

bullen 6y ago
Ok, obviously I will handle the race conditions. The point is if you can write joint parallel code with atomic variables why bother with OO?
- scott_s 6y ago
  OpenMP is not object-oriented. It is the correct version of what you alluded to, with 24 years of meeting the needs of the high-performance computing community.