Hacker News Reader

Comment by jlarocco | Hacker News Reader

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.

View on HN

Haskell 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.

The 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.

Can 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?

Yeah, 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.

currentPos 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.

Reply on news.ycombinator.com