Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Discovering a JDK Race Condition, and Debugging It in 30 Minutes with Fray

aoli.al

Post reply on HN
Print view View original

51–54 of 54 posts

Re: Discovering a JDK Race Condition, and Debugging It in 30 Minutes with Fray

#51

Post by brabel »

jbritton wrote: post #39
brabel wrote: post #28

Earlier quoted context omitted.

> Like, actors can trivially deadlock/livelock, Oh my ... you never seen a proper Actor language, have you? Have a look at Erlang and Pony, for starters. It will open your mind. This in particular is great: https://www.ponylang.io/discover/what-makes-pony-different/#... > Pony doesn’t have locks nor atomic operations or anything like that. Instead, the type system ensures at compile time that your concurrent program…

Perhaps there is some confusion here between data races and race conditions. Rust and Pony prevent data races, but not race conditions.

There's no confusion.

Re: Discovering a JDK Race Condition, and Debugging It in 30 Minutes with Fray

#52

Post by brabel »

gf000 wrote: post #30
brabel wrote: post #28

Earlier quoted context omitted.

> Like, actors can trivially deadlock/livelock, Oh my ... you never seen a proper Actor language, have you? Have a look at Erlang and Pony, for starters. It will open your mind. This in particular is great: https://www.ponylang.io/discover/what-makes-pony-different/#... > Pony doesn’t have locks nor atomic operations or anything like that. Instead, the type system ensures at compile time that your concurrent program…

Does preventing data races (which is not particularly hard if you are willing to give up certain properties, e.g. just immutability alone solves it) that much of a win? You just made a bunch of concurrent algorithms un-implementable that would give much better performance for the benefit of.. having all the other unsolvable issues with concurrency? Like, all the same issues are trivially reproducible at a higher leve…

> much of a win?

It's a huge win. Absolutely game changing.

> You just made a bunch of concurrent algorithms un-implementable

Exactly! That's a good thing! You think you need those buggy algorithms, you just don't, at least in 99% of cases.

Yes, you can still end up with inconsistencies when you perform actions without the necessary checks, but those cases that remain are extremely easy to find and fix (and even make completely impossible by design), when compared to the horrors of mutable state with locks.

Re: Discovering a JDK Race Condition, and Debugging It in 30 Minutes with Fray

#54

Post by ryeats »

this is really cool I want to use it for deterministim simulation testing. Question, isn't shadow locking essentially the same as continuations in virtual threads? how does this compare to replacing the scheduler in virtual threads? see https://jbaker.io/2022/05/09/project-loom-for-distributed-sy...
Post reply on HN