4 ms·
Honestly I don't think Haskell would have helped much here. That code is terrible from a thread safety perspective. If the author didn't read up on how to wri
by jlarocco 13y ago
Honestly I don't think Haskell would have helped much here.
That code is terrible from a thread safety perspective. If the author didn't read up on how to write good thread-safe code, it's unlikely he'd read up on Haskell, so he'd probably write bad code there, too.
- lelf 13y agoHaskell has type-safe software transactional memory for this stuff. And it's exponentially harder to get a program that compiles and has error like that.
- jlarocco 13y agoThe author didn't take the time to learn the very basics of thread safety. It's highly unlikely he would take the time to learn Haskell and software transactional memory.
- conroe64 13y agoCan you explain what makes it so terrible? At first glance it seems as if it is thread safe, and avoiding synchronization locks can provide a nice speed up. The notion that currentPos could be set to the new Point before the Point(int x, int y) constructor completed was completely surprising to me. Is that something that was obvious to you, or do you have other reasons to dislike it?
- hexagonc 13y agoYeah, this is very surprising to me. I simply didn't know that java worked that way and I've been programming in java for many years. I assumed that the memory that "currentPos" would eventually be bound to was fully initialized before the assignment operator remapped "currentPos" to the new value. I also assumed that binding a variable name to a new value is atomic across all threads.
- jlarocco 13y agocurrentPos is modified in one thread and read in a different thread, outside of a synchronized block, and without being protected by a mutex. It's a pretty straightforward recipe for disaster.