@WojciechMazur
This PR is still totally in progress, but could you just reviewthis commit?

In jsr166,VarHandle is used to achieve atomic operation(source), but if I understand correctly,VarHandle orAtomicReferenceFieldUpdater are not currently implemented in scala-native.

So I useCAtomicRef andIntrinsics here, but I want to make sure this is the right way. (PerhapsSynchronousQueue etc. use the same trick?)

So I use CAtomicRef and Intrinsics here, but I want to make sure this is the right way.

Yes, that would be the correct way to workaround these issues. Instead ofVarHandle useCAtomic as a wrapper for the underlying field pointer.

For AtomicFieldUpdaters they're partially supported, but not directly - we cannot use Java reflection-based API, howeverAtomicReferenceFieldUpdater and other are in fact defined asabstract class. We use this fact to implement their Intrinisc based version, without usage of reflection. It was used to makescala.collection.concurent.TrieMap work:definition,usage to port Java sources of stdlib definedhere. And we test the API/JDK compliancehere in unit-tests. However Intrinsic based Atomic Field Updaters are not yet defined in public API. In case of the ported source it should be fine, as it seems to be not using them, but I would try to create a ScalaNative specific API to create field updater without usage of intrinsics in users code. To some extent we might be able to do something similar with VarHandlers as well in the future.

Btw.LongAdder is not yet ported - it is using single-threaded implementation ported from Scala.js

Thanks for the detailed explanation! Ok, then I can proceed the porting the code related to varHandle.

LongAdder is not yet ported

Oops, I missed that. I'll portLongAdder in another PR before this.