I have a function like:

@Synchronized fun foo()

that now is being refactored to be

@Synchronized suspend fun foo()

(ℹ️ this is

kotlin.jvm.Synchronized

). The synchronisation is still needed if I don't know the context in which this will be called, right? Is there a way to also get rid of the synchronisation? Can I change to a single threaded executor to ensure calls to this function happen sequentially? Or would I need a mutex? Or is it fine as-is? I'm asking because

@Synchronized suspend fun foo()

looks a bit non-coroutinesque to me.

Synchronized will not work. You could use a mutex, but that changes the thread safety contract of that class. Would need to explore how it is being used. Before you exposed your synchronization scheme by making

this

be your lock. Also any other code in the class will need to use the mutex if they were synchronized before. They will then need to be

suspended

. The making access to it single threaded is a good option if possible. Other option is try to make it not deal with shared state. Trying to create a more functional programming style solution. Send immutable input and get immutable output. What solution works best depends on the problem being solved.

@kotlin.jvm.Synchronized

doesn't work on

suspend fun

- it wouldn't make sense to, as that flags the JVM to take a monitor with the function entry and exit, but as far as the JVM is concerned a

suspend fun

enters and exits at every suspend point

Gee, am I glad that I asked!

regardless of the number of threads in the executor, coroutines may be interleaved at suspend points

Yes, in my case it turned out that A called B, but that's a particular situation

if it's some other code, and the dispatcher is full, then I believe that by default it'll fall back to Dispatchers.Default - so it may still run concurrently

It looks like I'll have to do some more studying of the callers, order, mutable state, etc.