3 ms·

> While in Java we have only common/shared memory. That isn't entirely true. There are ThreadLocal variables in Java. However, these have some performance rami

by mryall 15y ago

> While in Java we have only common/shared memory. That isn't entirely true. There are ThreadLocal variables in Java. However, these have some performance ramifications and have to be carefully managed so they don't leak, basically because the system wasn't designed with this kind of storage in mind.

angusgr 15y ago
From my memories of Java ThreadLocals, these are still common/shared memory. The ThreadLocal property is a reference - a convenient way to scope access without locking - but the objects stored are still in shared memory. For example, correct me if I'm wrong, but in Java if you do something like: MyAwesomeClass myObject = new MyAwesomeClass(); myThreadLocal.set(myObject); myOtherObject.someField = myObject; Then the thread local and the field value are references to the same object, in the global heap. Any thread can get to "myOtherObject.someField" and change my thread's local copy. This specific example is probably bad design, but the underlying difference is between a shared memory design and a message passing share-nothing design, where the latter doesn't let you make that kind of mistake. In Erlang the paradigm is different enough that my bad example doesn't really translate[1], but even if two similar references were made equivalent, they're to _immutable_ objects not references - so from the programmer's point of view they're never shared at all. In addition, if you want to share something then you send a message so the other process (aka thread) always has their own distinct copy. [1] The process dictionary is kind of the same as thread local storage, but the kind of state you'd assign via a reference on a mutable field is dealt with differently.
- ww520 15y ago
  That is an explicit sharing of an object between the thread-local-storage and the global heap by the programmer. If MyAwesomeClass is readonly in all methods or it is copied when assigned to myOtherObject, then it's the same as Erlang.
- mryall 15y ago
  That's an interesting point. If the Erlang language can stop the programmer making mistakes like unintentional reference publishing across threads, that sounds fantastic.
  - angusgr 15y ago
    That's one of its major intentions. There's a fairly good summary here: http://ulf.wiger.net/weblog/2008/02/06/what-is-erlang-style-concurrency/ http://ulf.wiger.net/weblog/2008/02/06/what-is-erlang-style-...

by mryall 15y ago

angusgr 15y ago

From my memories of Java ThreadLocals, these are still common/shared memory. The ThreadLocal property is a reference - a convenient way to scope access without locking - but the objects stored are still in shared memory. For example, correct me if I'm wrong, but in Java if you do something like: MyAwesomeClass myObject = new MyAwesomeClass(); myThreadLocal.set(myObject); myOtherObject.someField = myObject; Then the thread local and the field value are references to the same object, in the global heap. Any thread can get to "myOtherObject.someField" and change my thread's local copy. This specific example is probably bad design, but the underlying difference is between a shared memory design and a message passing share-nothing design, where the latter doesn't let you make that kind of mistake. In Erlang the paradigm is different enough that my bad example doesn't really translate[1], but even if two similar references were made equivalent, they're to _immutable_ objects not references - so from the programmer's point of view they're never shared at all. In addition, if you want to share something then you send a message so the other process (aka thread) always has their own distinct copy. [1] The process dictionary is kind of the same as thread local storage, but the kind of state you'd assign via a reference on a mutable field is dealt with differently.

ww520 15y ago
That is an explicit sharing of an object between the thread-local-storage and the global heap by the programmer. If MyAwesomeClass is readonly in all methods or it is copied when assigned to myOtherObject, then it's the same as Erlang.
mryall 15y ago
That's an interesting point. If the Erlang language can stop the programmer making mistakes like unintentional reference publishing across threads, that sounds fantastic.
- angusgr 15y ago
  That's one of its major intentions. There's a fairly good summary here: http://ulf.wiger.net/weblog/2008/02/06/what-is-erlang-style-concurrency/ http://ulf.wiger.net/weblog/2008/02/06/what-is-erlang-style-...