
Memory Models: A Case for Rethinking Parallel Languages and Hardware (2010) - wheresvic1
https://cacm.acm.org/magazines/2010/8/96610-memory-models-a-case-for-rethinking-parallel-languages-and-hardware/fulltext
======
amelius
Since this is about parallel languages, why don't they say anything about
Erlang and related languages?

~~~
chrisseaton
Erlang has a trivial memory model, so it isn’t interesting in an article about
the challenges of memory models.

------
Tojot
The article says a lot about _concurrent_ programming, but little about
_parallel_ programming.

The naming is misleading.

~~~
twtw
The naming is not misleading, because the article says a lot about _parallel_
processing.

It is talking about memory consistency models, for heaven's sake. If you have
a uniprocessor, or any kind of concurrency without parallelism, it makes zero
sense to talk about memory consistency models because you automatically have
sequential consistency and don't have to think about it.

If you don't have a multiprocessor, you don't need to think about memory
consistency models. If you have a multiprocessor without parallelism, that's
your problem, not the author's.

~~~
gpderetta
Unfortunately because of compiler optimizations, memory models are important
even on uniprocessors.

~~~
twtw
Sure, and the article discusses that. I was thinking at the instruction level.
I tend to think of convincing the hardware to do what you want and convincing
the compiler to do what you want separately as an effect of writing code
before the languages had specified memory models.

EDIT: Though as I think about it I'm having a hard time thinking of a system
in which those compiler optimizations are problematic on a uniprocessor
system. It is definitely true that optimizations that are safe on a
uniprocessor break on a multiprocessor, but I can't think of any systems that
don't (effectively) have a memory barrier when switching between threads. SMT
wouldn't see a problem because both threads are on the same processor.

~~~
firethief
Imagine implementing a simple spinlock, but then substituting relaxed atomics
for acquire/release synchronization. The compiler can reorder taking the lock
relative to the protected operations and render the lock useless.

~~~
twtw
Thanks!

------
bullen
I think there are two ways forward; larger L1 caches or split memory between
cores, both have their problems.

To solve what this article argues about though, you can use my internet
platform: [https://github.com/tinspin/rupy](https://github.com/tinspin/rupy)

Java has excellent concurrency and non-blocking implementations.

Since it also has the only class-loader that is worth using, it's the only
programming language you can use for server-side joint parallel future proof
systems today.

