https://kotlinlang.org logo
#coroutines
Title
# coroutines
e

elizarov

08/08/2017, 2:52 PM
📣
kotlinx.atomicfu
version 0.1 was released. This is an utility library that enables writing efficient and idiomatic Kotlin code with atomic variables, CAS, etc, without having to write companion objects with
j.u.c.a.AtomicXXXFieldUpdater
instances. It is limited for now (only Maven projects are supported), but that is sufficient to use it in implementation of
kotlinx.coroutines
(next version will use it). It is currently published to a separate Bintray repository and will soon be synced to JCenter. More details here: https://github.com/Kotlin/kotlinx.atomicfu/blob/master/README.md
K 3
👍 6
It also has a pure kotlin API, so it will make it easier to port code with atomics to Kotlin/JS and Kotlin/Native in the future
v

voddan

08/08/2017, 8:00 PM
Sharing a public representation of atomic badly needs delegation
e

elizarov

08/08/2017, 8:02 PM
That must wait for compiler-intrinsic access to delegate, so that you can
::foo.delegate.compareAndSet
on a delegated property.
g

groostav

08/08/2017, 9:06 PM
can this be made more idiomatic with use of delegated properties? Following tornadoFX's example:
Copy code
val alpha by atomic(0.0)
val alphaCAS: AtomicUpdater<Double> = getUpdater(this::alpha)

val x = alpha //atomic read
alpha = x //atomic write

alphaCAS.loop { cur -> //while(true) volatile read

}
?
e

elizarov

08/09/2017, 12:03 AM
That is one possible approach, but I personally do not like this implicit connection between alpha and alphaCAS.... anyway, a reverse might work better:
Copy code
val fooAtomic = atomic(0)
val foo by fooAtomic
I'll think if I can implement this cleanly, so that only one volatile field is left is the bytecode after transfromation....
We’ll have to wait for this optimization in Kotlin compiler to be implemented: https://youtrack.jetbrains.com/issue/KT-14513
m

mikehearn

08/10/2017, 2:34 PM
May I suggest that kotlinx.atomic or kotlin.atomic would be a better package name?
and just to ensure I fully understand this - the goal is simply to avoid the additional heap overhead of the AtomicX wrapper objects?
3 Views