4 ms·
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
by 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 agoThe 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 agoAu 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 agoVery 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.
- pron 12y agoYou are free to rely on the guarantees made by a particular hardware architecture. The JVM implementation doesn't "take them away" -- the spec merely doesn't guarantee them. But if you do, then you might lose portability.
- zmmmmm 12y agoMy impression is that by not guaranteeing them it does take them away, because the implementation is free to implement them in any way they choose including in the compiler. So it will not matter if your code is executing on a processor that does not reorder instructions, Javac may already have done it to the byte code.
- pron 12y agoEven a C compiler is allowed to reorder instructions. How is any compiler supposed to know if you prefer performance (and therefore reordering) or to to rely on a processor-specific feature? That's why any language that runs on more than one architecture needs to define a language-level memory model.
- nradov 12y agoDouble checked locking works correctly in Java since version 1.5.
- mushishi 12y agoSo how do you deal with non-Java platforms? Do you use only those that have memory model defined?