4 ms·

I'll definitely watch the video and I have to say I don't know Clojure very well. I think we need to distinguish between in-app race conditions (a primitive ex

I'll definitely watch the video and I have to say I don't know Clojure very well. I think we need to distinguish between in-app race conditions (a primitive example is when you're trying to modify a data which cannot be written atomically), and situations where you have to maintain some order of operations because if you don't then the program won't work correctly _from the end-user's standpoint_. In concurrent programming safe operations are not composable, i.e. if you have >1 thread-safe operations then using those operations in parallel won't be thread-safe by itself). What I tried to say is that as you increase the level of abstraction (i.e. build something useful using the great constructs of Clojure), if concurrency still exists on that higher abstraction level then you need to think about synchronization, again. And the problem you'll face is really similar to those low-level issues when you try to protect a 64-bit long data structure in C. That's why I encourage everybody to think about these simple toy-problems even if they specifically never come up when you write programs using modern tools.

yogthos 13y ago
The reason threading is much easier in Clojure is due to immutability. Any changes made to data happen via revisions on existing data. This also means that any changes are inherently scoped to the appropriate code branch by default. Shared mutable data is handled by the STM in Clojure. The STM, in turn, relies on immutable data structures to work. Since data is immutable you can have optimistic locking. Reading existing state is perfectly safe even when a new state is being generated. This article http://blog.enfranchisedmind.com/2009/01/the-problem-with-stm-your-languages-still-suck/ http://blog.enfranchisedmind.com/2009/01/the-problem-with-st... does a great job explaining why it's notoriously difficult to make a working STM in an imperative language.
jwr 13y ago
> I think we need to distinguish between in-app race conditions (a primitive example is when you're trying to modify a data which cannot be written atomically), and situations where you have to maintain some order of operations because if you don't then the program won't work correctly _from the end-user's standpoint_. In concurrent programming safe operations are not composable, i.e. if you have >1 thread-safe operations then using those operations in parallel won't be thread-safe by itself). That's true. I also agree that regardless of the language or libraries used one needs to be aware of concurrency issues and understand them. The world is concurrent and there is no way around that. What I took issue with was the statement that you will have locks and even if they are in your libraries, they will come back to bite you. That is simply not true in case of complete languages/environments designed for concurrency. Clojure is one I know — and it isn't just a "library" that helps, it's the combination of language design, functional approach, data structures, immutable data and software transactional memory. Incidentally, the words "thread-safe" are really hard to encounter if you write in Clojure. I would imagine it is similar in Erlang.

yogthos 13y ago

The reason threading is much easier in Clojure is due to immutability. Any changes made to data happen via revisions on existing data. This also means that any changes are inherently scoped to the appropriate code branch by default. Shared mutable data is handled by the STM in Clojure. The STM, in turn, relies on immutable data structures to work. Since data is immutable you can have optimistic locking. Reading existing state is perfectly safe even when a new state is being generated. This article http://blog.enfranchisedmind.com/2009/01/the-problem-with-stm-your-languages-still-suck/ http://blog.enfranchisedmind.com/2009/01/the-problem-with-st... does a great job explaining why it's notoriously difficult to make a working STM in an imperative language.

jwr 13y ago

> I think we need to distinguish between in-app race conditions (a primitive example is when you're trying to modify a data which cannot be written atomically), and situations where you have to maintain some order of operations because if you don't then the program won't work correctly _from the end-user's standpoint_. In concurrent programming safe operations are not composable, i.e. if you have >1 thread-safe operations then using those operations in parallel won't be thread-safe by itself). That's true. I also agree that regardless of the language or libraries used one needs to be aware of concurrency issues and understand them. The world is concurrent and there is no way around that. What I took issue with was the statement that you will have locks and even if they are in your libraries, they will come back to bite you. That is simply not true in case of complete languages/environments designed for concurrency. Clojure is one I know — and it isn't just a "library" that helps, it's the combination of language design, functional approach, data structures, immutable data and software transactional memory. Incidentally, the words "thread-safe" are really hard to encounter if you write in Clojure. I would imagine it is similar in Erlang.