4 ms·

> No, no, no. If you are writing multithreaded programs, you _will_ have locks, period. The question is whether you explicitly use them or if they are hidden so

by jwr 13y ago

> No, no, no. If you are writing multithreaded programs, you _will_ have locks, period. The question is whether you explicitly use them or if they are hidden somewhere in your libraries, frameworks, etc. Actually, the latter are much more difficult to debug. You say that and then proceed to call the article ridiculous. Well, I write and maintain large applications in Clojure. The code uses a multitude of threads for various purposes, with different lifetimes. And I've yet to see a single explicit lock. What's more important, though, is that I've yet to see a race condition, a deadlock, or data corruption, which I find pretty impressive. I do agree that you need to understand what is happening — but I disagree with your assumption that the basic tools are all on the same level. They are not, which Clojure clearly demonstrates. I won't go into details, because Rich Hickey explains it much, much better than I ever will be able to — here's an example of his talk: http://www.youtube.com/watch?v=dGVqrGmwOAw http://www.youtube.com/watch?v=dGVqrGmwOAw

eXpl0it3r 13y ago
I guess that points out another issue with the article - it talks about programming in general and doesn't take into account that it's way easier to write multi-threaded applications with languages that are explicitly created for developing multi-threaded application and languages that just happen to support threading. So comparing for example Clojure and C++ in regards to multi-threading Clojure will of course win, since C++ only recently got official standardized threading implemented and is far away from a really good concurrency support.
- nly 13y ago
  C++ will, of course, win the moment you let 3rd party libraries in the door. Oh, sorry... that's just another vague generalisation.
sz4kerto 13y ago
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.
andyjohnson0 13y ago
Do your large applications use databases, the filesystem, console I/O, etc?
- jwr 13y ago
  Yes, very much so.

by jwr 13y ago

eXpl0it3r 13y ago

I guess that points out another issue with the article - it talks about programming in general and doesn't take into account that it's way easier to write multi-threaded applications with languages that are explicitly created for developing multi-threaded application and languages that just happen to support threading. So comparing for example Clojure and C++ in regards to multi-threading Clojure will of course win, since C++ only recently got official standardized threading implemented and is far away from a really good concurrency support.

nly 13y ago
C++ will, of course, win the moment you let 3rd party libraries in the door. Oh, sorry... that's just another vague generalisation.

sz4kerto 13y ago

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.

andyjohnson0 13y ago

Do your large applications use databases, the filesystem, console I/O, etc?

jwr 13y ago
Yes, very much so.