Timeline for Does immutability entirely eliminate the need for locks in multi-processor programming?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 14, 2013 at 11:56 | history | edited | GlenPeterson | CC BY-SA 3.0 | Fixed typo. |
| Oct 26, 2012 at 12:07 | vote | accept | GlenPeterson | ||
| Oct 25, 2012 at 17:48 | comment | added | C. A. McCann | @JimmyHoffa: MVars are a low-level mutable concurrency primitive (technically, an immutable reference to a mutable storage location), not too different from what you'd see in other languages; deadlocks and race conditions are very possible. STM is a high-level concurrency abstraction for lock-free mutable shared memory (very different from message-passing) that allows composable transactions with no possibility of deadlocks or race conditions. Immutable data is just thread-safe, nothing else to say about it. | |
| Oct 25, 2012 at 17:15 | comment | added | Telastyn | @jimmyhoffa - The most common example is IO. Even if the language is immutable, your database/website/file is not. Another is your typical map/reduce. Immutability means that the aggregation of the map is more foolproof, but you still need to handle the 'once all the map is done in parallel, reduce' coordination. | |
| Oct 25, 2012 at 14:35 | comment | added | Jimmy Hoffa | @stonemetal interesting, in my 4 months with Haskell I had not even heard of Mvars yet, I always heard to use STM for concurrency state communication which behaves more like Erlang's message passing I thought. Though perfect example of immutability not solving concurrent issues I can think of is updating a UI, if you have 2 threads trying to update a UI with different versions of data, one may be newer and therefore needs to get the second update so you have a race condition where you must guarantee the sequencing somehow.. Interesting thought.. Thanks for the details | |
| Oct 25, 2012 at 14:04 | comment | added | stonemetal | @JimmyHoffa In an immutable language you still need someway to update state between threads. The two most immutable languages I know (Clojure and Haskell) provide a reference type(atoms and Mvars) that provide a way to ship modified state between threads. The semantics of their ref types prevent certain types of concurrency errors, but others are still possible. | |
| Oct 25, 2012 at 4:54 | comment | added | Jimmy Hoffa | +1 This makes sense, but could you give an example of where in a deeply immutable language you still have to worry about handling concurrency properly? You state that you do, but such a scenario isn't clear to me | |
| Oct 24, 2012 at 22:56 | history | edited | Telastyn | CC BY-SA 3.0 | added 95 characters in body |
| Oct 24, 2012 at 22:51 | history | answered | Telastyn | CC BY-SA 3.0 |