are coroutines thread safe, like should i use atomic types?

# coroutines

[Animesh Sahu]

are coroutines thread safe, like should i use atomic types?

[gildor]

It depends what exactly you are doing

[Animesh Sahu]

I'm implementing/typing to achieve lateinit vals using delegation, since the call is blocking i dont want to block thread while instantiating object, using IO dispatcher to set the val, and ensuring no override can be done.

private val value= AtomicReference<T>()
if (!value.compareAndSet(null, value)) {...}

vs

private var value: T? = null
if (this.value != null) {...}

[Animesh Sahu]

in case of dispatching to io pool, should atomic references be used

[Animesh Sahu]

Ohh wow lol https://discuss.kotlinlang.org/t/idiomatic-way-for-asynchronous-construction/14560
fake constructors are great xd, i would just do all async work in there before initializing the object

[zak.taccardi]

a coroutine is thread safe

[zak.taccardi]

but if you access state from outside that coroutine and that state isn’t thread safe, then you will have a race condition

[zak.taccardi]

you can think of thread safety as something being thread safe based on the context it’s being written to and read from

[zak.taccardi]

AtomicBoolean is thread safe by itself, but use it in an object that isn’t thread safe and your Boolean is no longer thread safe

[zak.taccardi]

coroutines are no different

[zak.taccardi]

but using a coroutine + message passing is an awesome way to achieve thread safety.

https://kotlinlang.org/docs/reference/coroutines/shared-mutable-state-and-concurrency.html#actors

[SrSouza]

Sad that Actors is not multiplataform

[zak.taccardi]

Why aren't they?

[zak.taccardi]

You can replicate an actor with a channel that you just launch immediately and maintain a reference to it