We have an argument in our team, regarding cache coherency and how coroutine context switch affect it. Imagine the situation: 1. Coroutine C modifies object O 2. Coroutine C yelds, thread is switching to another coroutine 3. Coroutine C is resumed by another thread, uses data from O and updates object O again 4. Process repeats, context switching is happening a lot, and usually under few milliseconds Note: there is no concurrent access to object O, only a single coroutine works with O at any point in time Is there a chance that updates made by one of the threads in iteration N are not visible by another thread on iteration N+1? In other words, what happens with CPU cache when coroutines are switched way too fast? Is it coherent no matter what?

context switching machinery inside coroutines should have all the necessary memory barriers to ensure writes from one thread are published when it suspends and are visible to other threads when they resume

Are you passing the object around or is object O some kind of global?

if it's possible that

action()

could be invoked by multiple coroutines at once, then you may have an issue

i don’t know enough about your implementation, but i’d be concerned about safe publication of both the field and the values inside it. (state is a

var

so you could be changing both).

State is not leaving Action until computation is (partially) completed, it's basically an accumulator, but it's somewhat algorithmically complex code. Developer who wrote the code doesn't know where the bug is and trying to blame CPU cache (current workaround involves copying a state on certain safepoints), saying coroutines do not guarantee HB (happens before) relationship between context switch, while me and other developer are opposite of this.

coroutine does, and if you can come up with a case where it doesn't, file a bug

private var state = ...

this can always have different values on different threads due to the way modern CPUs work (especially different threads can having different on die caches), regardless of whether you use coroutines or not. for JVM you can use `@Volatile` to ensure that does not happen. Since you explicitly say you switch to a different thread and are not doing this, CPU cache is a very likely cause.

the atomics inside coroutines are suppose to do the equivalent of publishing volatile. if they don't they should be fixed (just like the Scala issue in the video above)

But they’re not using coroutines to access data, it’s just a

var

somewhere. Kotlin doesn’t even make assumptions about the underlying memory model (in this case JVM) or provide an abstraction to libraries (such as coroutines) to deal with this. Also it’d be pretty terrible if coroutines made all your writes only to main memory, your program would be an order or magnitude slower just for using coroutines. I think maybe you mean a var inside a suspend method, which effectively lives on a context under control of coroutines itself, like:

class Action {


   suspend fun action() { 
      private var state = ...
      ... 
   }
}

on jvm, a volatile write also publishes all other writes up to that point, and conversely on read

@Tijl

this can always have different values on different threads due to the way modern CPUs work (especially different threads can having different on die caches), regardless of whether you use coroutines or not.

for JVM you can use `@Volatile` to ensure that does not happen. Since you explicitly say you switch to a different thread and are not doing this, CPU cache is a very likely cause.

I've spent few hours refreshing JMM and other topics, and as it seems, there is no need for volatile b.c. coroutines' atomics will put a fence anyway during suspend (it'll flush everything). And because there is no data race (e.g. only a single thread runs an action), there is no need to use atomics either.

This particular question is directly answered here https://proandroiddev.com/what-is-concurrent-access-to-mutable-state-f386e5cb8292