Java Concurrency – Understanding the Basics of Threads • Hacker News Board

Re: Java Concurrency – Understanding the Basics of Threads

#41

Post by formerly_proven » Sat, Oct 31, 2020, 7:04 PM UTC

JackFr wrote: post #17

FpUser wrote: post #6

Earlier quoted context omitted.

The concepts of threads and concurrent data access is simple enough for any decent programmer to comprehend. There is no hell here. Sure there are some complex cases but complex cases will arise in many situations when programming things. And achieving concurrency without shared memory is impossible in general case. Sure it is possible to isolate such access to a separate layer and make it transparent for the rest of…

The problem for novices is that a program that behaves correctly looks a lot like a correct program. Until one day it doesn’t. And because you’re in production and getting random spurious failures, the panicked (but common) reaction is to wrap every shared resource in a synchronized block. Which makes an incorrect implementation worse but possibly correct.

Novices don't build working concurrent systems of any kind with any toolkit, period. Concurrency is hard and thinking all the "concurrency problems" go away with some message passing is both ludicrous and dangerous. Fearless concurrency can only be attained through understanding, not by thinking all your problems went away because you're using a "cool approach".

Re: Java Concurrency – Understanding the Basics of Threads

#42

Post by abhishekjha » Sat, Oct 31, 2020, 7:08 PM UTC

JSavageOne wrote: post #32

I'm not a Java developer, but isn't RxJava the current best practice around managing concurrency in Java? I thought the consensus was that manually dealing with thread creation is too error-prone and unmanagable.

We are using the Akka framework so as to not to have to deal with threads directly. Message passing and immutable objects simplify a lot while adding one more abstraction layer.

Re: Java Concurrency – Understanding the Basics of Threads

#43

Post by abhishekjha » Sat, Oct 31, 2020, 7:10 PM UTC

formerly_proven wrote: post #41

JackFr wrote: post #17

Earlier quoted context omitted.

The problem for novices is that a program that behaves correctly looks a lot like a correct program. Until one day it doesn’t. And because you’re in production and getting random spurious failures, the panicked (but common) reaction is to wrap every shared resource in a synchronized block. Which makes an incorrect implementation worse but possibly correct.

Novices don't build working concurrent systems of any kind with any toolkit, period. Concurrency is hard and thinking all the "concurrency problems" go away with some message passing is both ludicrous and dangerous. Fearless concurrency can only be attained through understanding, not by thinking all your problems went away because you're using a "cool approach".

Surprisingly this is what the akka framework promises : Message passing and immutability of objects.

Re: Java Concurrency – Understanding the Basics of Threads

#44

Post by mrkeen » Sat, Oct 31, 2020, 7:20 PM UTC

cultus wrote: post #22

Project Loom[0] is going to be coming out at some point. That brings direct JVM support for delimited continuations and fibers. That's really going to change and simplify JVM concurrency and I think many other things. Delimited continuations can be used to implement algebraic effects, which is exciting for functional programming. [0] https://openjdk.java.net/projects/loom/

> Delimited continuations can be used to implement algebraic effects, which is exciting for functional programming.

How-so? I thought the type system was the precluding factor for algebraic effects, not the threading model.

Re: Java Concurrency – Understanding the Basics of Threads

#45

Post by vips7L » Sat, Oct 31, 2020, 7:20 PM UTC

JSavageOne wrote: post #32

I'm not a Java developer, but isn't RxJava the current best practice around managing concurrency in Java? I thought the consensus was that manually dealing with thread creation is too error-prone and unmanagable.

No, ExecutorServices are the current best practice around managing concurrency in Java. RxJava is only something you should use if you have specific performance requirements (with data to back it up), and you need the Observable pattern.

Re: Java Concurrency – Understanding the Basics of Threads

#46

Post by mrkeen » Sat, Oct 31, 2020, 7:21 PM UTC

cle wrote: post #29

yetkin wrote: post #4

The problem is not the threads, it is the mutations of variables which boost the complexity of the code. So a tutorial on creation of theads actually an invitation to hell. Nothing is cool about it. Cool thing is achieving concurrency without threads/race conditions/shared memory

A computer is a mutation machine, you cannot escape mutation by hand-waving it away. If you are writing programs in which you can achieve concurrency without threads and shared memory, it’s because you’re building on the shoulders of all the engineers who didn’t hand-wave it away. Many of us, due to product requirements, don’t have the luxury of using higher level abstractions like that.

And yet we're comfortable hand-waving GOTO away - that is, not calling computers GOTO machines.

Re: Java Concurrency – Understanding the Basics of Threads

#47

Post by wging » Sat, Oct 31, 2020, 7:22 PM UTC

robto wrote: post #16

dbsmith83 wrote: post #7

Earlier quoted context omitted.

Idk about GP, but one book I highly recommend is Java Concurrency in Practice - https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz... It's old, but the material holds up well since it covers a lot of fundamentals

We were an all-Java shop and we were considering how to make our application a SAAS cloud application. Our senior engineers read this book. They all agreed that it was very educational, but the conclusion was that Java concurrency in practice has too many footguns, and so we ended up adopting Clojure. I think modern Java has better support for it, but if you've got mutable state spread throughout your application you…

Rich Hickey is supposed to have said that he created Clojure because he was tired of telling people to read that book.

Best I can find as a source for now is https://www.youtube.com/watch?v=2y5Pv4yN0b0 -- I thought there was a link somewhere to Hickey himself saying this, but can't find it.

Re: Java Concurrency – Understanding the Basics of Threads

#48

Post by mrkeen » Sat, Oct 31, 2020, 7:56 PM UTC

mrfox321 wrote: post #12

yetkin wrote: post #4

The problem is not the threads, it is the mutations of variables which boost the complexity of the code. So a tutorial on creation of theads actually an invitation to hell. Nothing is cool about it. Cool thing is achieving concurrency without threads/race conditions/shared memory

Can databases be efficiently implemented without shared access? Can message passing accomplish this at the same level of performance? although I agree that simplifying resource access should probably be considered before fully shared state.

> Can databases be efficiently implemented without shared access?

Let me ask a different question: Why did databases take off in the way they did? Sure they persist stuff to disk, but so do files. What they offer is a concurrency model so good that you almost never think about it. Beginner programmers can competently write large, concurrent systems by writing single-threaded programs which are backed by a central DB, without even knowing the term "race condition".

If beginner database articles told users how to make database Threads, Thread groups, and how to signal and catch interruptions, I don't think databases would have enjoyed nearly as much popularity.

While Threads are fundamental to Java concurrency, I kinda agree with yetkin's point. It introduces the Thread footgun without even paying lip service to the problems of shared, mutable state.

Re: Java Concurrency – Understanding the Basics of Threads

#49

Post by mrkeen » Sat, Oct 31, 2020, 8:01 PM UTC

formerly_proven wrote: post #41

JackFr wrote: post #17

Earlier quoted context omitted.

The problem for novices is that a program that behaves correctly looks a lot like a correct program. Until one day it doesn’t. And because you’re in production and getting random spurious failures, the panicked (but common) reaction is to wrap every shared resource in a synchronized block. Which makes an incorrect implementation worse but possibly correct.

Novices don't build working concurrent systems of any kind with any toolkit, period. Concurrency is hard and thinking all the "concurrency problems" go away with some message passing is both ludicrous and dangerous. Fearless concurrency can only be attained through understanding, not by thinking all your problems went away because you're using a "cool approach".

It's pretty easy to make the leap from individual SQL statements to SQL statements which are wrapped in a transaction.

Re: Java Concurrency – Understanding the Basics of Threads

#50

Post by teslalang » Sat, Oct 31, 2020, 8:02 PM UTC

secondcoming wrote: post #34

FpUser wrote: post #24

Earlier quoted context omitted.

If the resource is shared and being accessed from many threads and is both written to and read from then it is the correct behavior to to lock it with the proper type of lock at access time. Depending on resource it might be possible to split it into few with more granular access. As for novices: they are called that for reason and supposed to be under supervision rather than allowed running wild.

Why is this being downvoted? It's the truth. HN needs to only allow downvotes that have an accompanying explanation comment.

As with most other compromised social sites, no badthink allowed here and how dare you.