5 ms·

Java Memory Model Pragmatics

108 points by t__crayford 12y ago

marcosscriven 12y ago
Just an FYI - 'select over' doesn't work on iOS Safari.
- josephlord 12y ago
  Copy and paste to notes was my work around.
theocs 12y ago
This is very technical, most likely way past what 99% of developers both need to care about and have to care about. Given that most developers work at best with embarrassingly parallel problems they wouldn't need to know much of these details. But if you're up for it: It's a very rewarding feeling when you're both allowed to figure these things out and someone are also paying you while you figure it out.
- mahmud 12y ago
  Who cares about "most developers". This is interesting for its own sake.
virmundi 12y ago
In the section about nasal demons, did anyone else think the right answer was 12 too? I figured the parens make the context local so the ++ had to occur after the add.
- aeonsky 12y ago
  There is no right answer to that problem.
  - virmundi 12y ago
    I know that was the point, but I thought the spec on ++ is that it occurs after the statement. I thought the spec on parens is that they are sub statement. Since there are two ++ occurring, it is odd, but I thought by spec the 12 is right.
    - the_af 12y ago
      The spec says "The value of the operand of the preﬁx ++ operator is incremented. The result is the new value of the operand after incrementation. The expression ++E is equivalent to (E+=1)." I think the problem in the example from the article is that the spec doesn't say what happens to i when it appears twice in the same expression. What is the "current" value of i each increment sees? Maybe they both see the initial value 5, and the result is (5+1) + (5+1) = 12 like you say. But compiling the example with gcc 4.6.3 gives me 14 as a result! It seems as if gcc is seeing the two updates and then replacing each occurrence of i with the final value 7 (but I'm guessing). I guess the point is that, since it isn't in the spec, each implementation of C is free to do whatever the implementors decided.
zmmmmm 12y ago
The memory model seems to be the real achilles heel for concurrency in Java. In the end with a only little bit of work one can master the concurrency primitives and they are quite usable. However understanding the full ramifications of the memory model is pretty much beyond mere mortals. As a result it is hard to do anything else than stick to established patterns and / or toolkits and frameworks if you don't want to set yourself up for insidious issues that are nearly impossible to reproduce.
- pcwalton 12y ago
  > The memory model seems to be the real achilles heel for concurrency in Java. I'd expand it beyond Java to shared-everything models in general. Any language with a shared-everything model is going to incur all this complexity. At least Java goes through this pain to ensure memory safety in the presence of unsynchronized accesses from multiple threads.
- fiatmoney 12y ago
  The memory model is actually relatively straightforward on the user side; it's significantly more complicated on the implementer side. In most cases you can get away with coarser constructs (which are higher-performing anyway, eg task parallelism vs. trying to decompose an individual operation) and only dive into the language lawyering semantics when you, eg, really really need a lockfree concurrent linked list.
- noelwelsh 12y ago
  Au contraire, the fact that Java actually has a memory model means one can reason about concurrency in a way impossible on other platforms. As you note you rarely need to concern yourself with the details of the memory model as most of us are users, not designers, of concurrency primitives. But you should you need to design a new primitive you can actually have some guarantees it will work in a cross-platform manner, which is more than you an say about any other platform I know of.
  - zmmmmm 12y ago
    Very true! Having it defined is very important. However part of the problem is that definition actually takes away guarantees that many CPUs (eg. x86) give you. For example double checked locking works in x86 but famously not in Java. So the fact is that Java is giving you in some ways a less sequential model than what you started with is what makes it particularly insidious.
starnixgod 12y ago
Was the English version of this talk recorded? I found the talk in Russian[1], but with my understanding of the Russian language, it's impossible to watch. 1. https://www.youtube.com/watch?v=1FX4zco0ziY https://www.youtube.com/watch?v=1FX4zco0ziY
- ivank 12y ago
  I think you meant to link to https://www.youtube.com/watch?v=iB2N8aqwtxc https://www.youtube.com/watch?v=iB2N8aqwtxc
majke 12y ago
Implementator's perspective: * http://gee.cs.oswego.edu/dl/jmm/cookbook.html http://gee.cs.oswego.edu/dl/jmm/cookbook.html

108 points by t__crayford 12y ago

marcosscriven 12y ago

Just an FYI - 'select over' doesn't work on iOS Safari.

josephlord 12y ago
Copy and paste to notes was my work around.

theocs 12y ago

This is very technical, most likely way past what 99% of developers both need to care about and have to care about. Given that most developers work at best with embarrassingly parallel problems they wouldn't need to know much of these details. But if you're up for it: It's a very rewarding feeling when you're both allowed to figure these things out and someone are also paying you while you figure it out.

mahmud 12y ago
Who cares about "most developers". This is interesting for its own sake.

virmundi 12y ago

In the section about nasal demons, did anyone else think the right answer was 12 too? I figured the parens make the context local so the ++ had to occur after the add.

aeonsky 12y ago
There is no right answer to that problem.
- virmundi 12y ago
  I know that was the point, but I thought the spec on ++ is that it occurs after the statement. I thought the spec on parens is that they are sub statement. Since there are two ++ occurring, it is odd, but I thought by spec the 12 is right.
  - the_af 12y ago
    The spec says "The value of the operand of the preﬁx ++ operator is incremented. The result is the new value of the operand after incrementation. The expression ++E is equivalent to (E+=1)." I think the problem in the example from the article is that the spec doesn't say what happens to i when it appears twice in the same expression. What is the "current" value of i each increment sees? Maybe they both see the initial value 5, and the result is (5+1) + (5+1) = 12 like you say. But compiling the example with gcc 4.6.3 gives me 14 as a result! It seems as if gcc is seeing the two updates and then replacing each occurrence of i with the final value 7 (but I'm guessing). I guess the point is that, since it isn't in the spec, each implementation of C is free to do whatever the implementors decided.

zmmmmm 12y ago

The memory model seems to be the real achilles heel for concurrency in Java. In the end with a only little bit of work one can master the concurrency primitives and they are quite usable. However understanding the full ramifications of the memory model is pretty much beyond mere mortals. As a result it is hard to do anything else than stick to established patterns and / or toolkits and frameworks if you don't want to set yourself up for insidious issues that are nearly impossible to reproduce.

pcwalton 12y ago
> The memory model seems to be the real achilles heel for concurrency in Java. I'd expand it beyond Java to shared-everything models in general. Any language with a shared-everything model is going to incur all this complexity. At least Java goes through this pain to ensure memory safety in the presence of unsynchronized accesses from multiple threads.
fiatmoney 12y ago
The memory model is actually relatively straightforward on the user side; it's significantly more complicated on the implementer side. In most cases you can get away with coarser constructs (which are higher-performing anyway, eg task parallelism vs. trying to decompose an individual operation) and only dive into the language lawyering semantics when you, eg, really really need a lockfree concurrent linked list.
noelwelsh 12y ago
Au contraire, the fact that Java actually has a memory model means one can reason about concurrency in a way impossible on other platforms. As you note you rarely need to concern yourself with the details of the memory model as most of us are users, not designers, of concurrency primitives. But you should you need to design a new primitive you can actually have some guarantees it will work in a cross-platform manner, which is more than you an say about any other platform I know of.
- zmmmmm 12y ago
  Very true! Having it defined is very important. However part of the problem is that definition actually takes away guarantees that many CPUs (eg. x86) give you. For example double checked locking works in x86 but famously not in Java. So the fact is that Java is giving you in some ways a less sequential model than what you started with is what makes it particularly insidious.

starnixgod 12y ago

Was the English version of this talk recorded? I found the talk in Russian[1], but with my understanding of the Russian language, it's impossible to watch. 1. https://www.youtube.com/watch?v=1FX4zco0ziY https://www.youtube.com/watch?v=1FX4zco0ziY

ivank 12y ago
I think you meant to link to https://www.youtube.com/watch?v=iB2N8aqwtxc https://www.youtube.com/watch?v=iB2N8aqwtxc

majke 12y ago

Implementator's perspective: * http://gee.cs.oswego.edu/dl/jmm/cookbook.html http://gee.cs.oswego.edu/dl/jmm/cookbook.html