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

Re: Java Concurrency – Understanding the Basics of Threads

#51

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

ubercow13 wrote: post #35

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.

What's a better alternative to synchronizing access to shared resources?

Treat it like GC and don't leave it up to the programmer.

Re: Java Concurrency – Understanding the Basics of Threads

#52

Post by formerly_proven » Sat, Oct 31, 2020, 8:11 PM UTC

mrkeen wrote: post #49

formerly_proven wrote: post #41

Earlier quoted context omitted.

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.

Excellent example for making my point, since "just wrap it in a transaction" usually leads to concurrency bugs like the beloved lost update.

Re: Java Concurrency – Understanding the Basics of Threads

#53

Post by cle » Sat, Oct 31, 2020, 8:12 PM UTC

mrkeen wrote: post #46

cle wrote: post #29

Earlier quoted context omitted.

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.

There are thousands of engineers (at least) who use it or its equivalent every day. Just because they’ve built abstractions that allow you to ignore it, doesn’t mean nobody has to deal with it anymore.

Re: Java Concurrency – Understanding the Basics of Threads

#54

Post by grandinj » Sat, Oct 31, 2020, 8:44 PM UTC

LgWoodenBadger wrote: post #14

With Futures and Executors/ExecutorServices I find that I rarely ever need to use raw Threads these days. Most of the thread-safety issues commonly encountered are eliminated with this approach as well.

Except for that pesky swallowing of exceptions, I agree

Re: Java Concurrency – Understanding the Basics of Threads

#55

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

formerly_proven wrote: post #52

mrkeen wrote: post #49

Earlier quoted context omitted.

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

Excellent example for making my point, since "just wrap it in a transaction" usually leads to concurrency bugs like the beloved lost update.

This is not something I'm familiar with. What's the beloved lost update and what transactions are you using that suffer from it?

Re: Java Concurrency – Understanding the Basics of Threads

#56

Post by pjmlp » Sat, Oct 31, 2020, 9:45 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.

RxJava got hyped in Android before Google went with Kotlt first, now they are into co-routines and depending on the Jetpack project, Java developers might still be able to use it, or be forced into Kotlin.

Re: Java Concurrency – Understanding the Basics of Threads

#57

Post by FpUser » Sat, Oct 31, 2020, 9:47 PM UTC

mrkeen wrote: post #51

ubercow13 wrote: post #35

Earlier quoted context omitted.

What's a better alternative to synchronizing access to shared resources?

Treat it like GC and don't leave it up to the programmer.

An make a programmer unable to achieve highest performance when needed. We leave in supposedly free world. If you want to be "protected" be my guest and use languages with GC. Plenty of those. For somebody who need the opposite and uses "unprotected" tools - leave them alone. You have no rights to decide how other people do their work unless they're under your direct control.

Re: Java Concurrency – Understanding the Basics of Threads

#58

Post by FpUser » Sat, Oct 31, 2020, 9:51 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.

HN uses downvotes mostly to boo the people with opinions deviating from common party line. As for reasonable explanation - you're asking too much. Programming as many other things often are treated as the religion. No arguments, it just is.

Re: Java Concurrency – Understanding the Basics of Threads

#59

Post by FpUser » Sat, Oct 31, 2020, 9:57 PM UTC

formerly_proven wrote: post #52

mrkeen wrote: post #49

Earlier quoted context omitted.

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

Excellent example for making my point, since "just wrap it in a transaction" usually leads to concurrency bugs like the beloved lost update.

If you're talking database like transaction it "usually" leads to concurrency bugs only if the transaction level is not strictly serializable. It does not hurt to know things before labeling them.

Re: Java Concurrency – Understanding the Basics of Threads

#60

Post by FpUser » Sat, Oct 31, 2020, 10:02 PM UTC

abhishekjha wrote: post #43

formerly_proven wrote: post #41

Earlier quoted context omitted.

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.

Software usually has state (unless that state is completely kept and managed externally in a database for example). And the state mutates. Simple case example is a big array that has to be processed in place.