Fork me on GitHub
#core-async
<
2018-05-04
>
leonoel11:05:32

what is the reason why go state is held in a java.util.concurrent.atomic.AtomicReferenceArray instead of an unsynchronized array ?

tbaldridge13:05:09

@leonoel whenever a go block pauses execution of the block can jump to a new thread. The Java memory model does not guarantee that all writes to the array would be flushed before the new thread picks up the go block.

tbaldridge13:05:42

Another option would be to create a class with fields marked as volatile, but doing this inline, inside a macro, via normal clojure code is impossible.

tbaldridge13:05:31

Now days it might be possible to do all of this via volatile!, but volatile came after core.async was released

leonoel14:05:32

the JMM ensures that all writes performed before the channel lock release are made visible to threads subsequently aquiring the same lock

leonoel14:05:06

Am I missing something ?

tbaldridge14:05:41

what writes though, I'm pretty sure that's not true for non volatile fields

tbaldridge14:05:51

I remember when I made the change from a normal array to a AtomicReferenceArray I did a fair amount of research on the topic and talked to a few people and came to the conclusion that it was needed. But that was also about 5 years ago.

tbaldridge14:05:00

I'm more than happy to be corrected.

leonoel14:05:08

I have no doubt you have think about this more than I am but I can't really figure out a scenario where visibility would not be enforced

leonoel14:05:55

and I'm pretty sure JMM guarantees applies to unsynchronized fields as well, if it were not the case the linked lists inside channels would be unsafe

tbaldridge14:05:03

that's a good point

leonoel14:05:49

I've absolutely zero insight about performance impact though