Is low level synchronized block still cool in coroutines? The usual copy load+save use case... Or maybe updating StateFlow instance via reducing of the current value + change

Depends on what you are trying to achieve.

synchronized

over suspension points is not cool (expect issues), and should be replaced by

Mutex

, but otherwise, it's fine in the JVM.

@Synchronized

just sets a flag on the method in the classfile, so it probably doesn't cause anything to break, but it won't work either; as far as the JVM is concerned, the function is being called and is returning at every suspension point

Yes I should have been clearer. Its only blocking code within the synchronized block

synchronized {
   stateFlow.value = stateFlow.value.copy(foo = bar)
}

You don't need a lock for that,

MutableStateFlow

has a

compareAndSet

method you can use for lock-free atomic updates: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-mutable-state-flow/compare-and-set.html

also, if you're trying to handle updates coming from multiple sources, maybe you could try to process them in a single coroutine, effectively serializing them

@Zach Klippenstein (he/him) [MOD] ehm I might be confused but how would I use that? Id expect something like this

val mutableStateFlow = MutableStateFlow(State())
mutableStateFlow.set {
    copy(counter + 1)
}

data class State(counter: Int = 0)

and have the set function be thread safe

Not hard to write that function yourself:

lateinit var old: YourState
lateinit var new: YourState
do {
  old = mutableStateFlow.value
  new = old.copy(foo = bar)
} while (!mutableStateFlow.compareAndSet(old, new))

yea I had this so far

fun <T> MutableStateFlow<T>.set(reduce: T.() -> T) {
    synchronized(this) {
        value = value.reduce()
    }
}

so the difference is the classic lock vs lockfree concurrency thing? nothing coroutine about this right?

But using a mutex is probably simpler

thread mutex or coroutine Mutex?

Coroutine mutex

hmm why, does it matter? is it to make it multiplatform friendly in future?

@ursus Threads take up space in memory (RAM for their heap and stack), so blocking them just to wait is wasting them.

im aware thanks, this is however just a simple assigment just need to make sure everyone sees the latest value before updating it, bit of a overkill to use some highlevel coroutine object, no?

@Zach Klippenstein (he/him) [MOD] Other reasons to pick coroutines mutex over java.util.concurrent mutex?

do not use java.util.concurrent locks in a coroutine. it'll block instead of suspending

Im almost sure all sqlite libraries will still block transactions blocks on thread level regardless, I dont this its useless

assuming you're talking about java.util.concurrent.locks.ReentrantLock (there's no standard type specifically called Mutex), you also can't use it because it must be unlocked on the same thread that it was locked on

No im talking about synchronized block. Underlying dispatcher thread will get blocked and wait as usual. Theoretically less performant but will work correctly, no?

no, even with a synchronized block, as soon as you hit a suspension point, the actual JVM function returns

I mean if sychnronization block doesnt work with coroutines, then how can all the java concurent data structures work? im sure its not just lockless threadsafety in all of them

atomic references work

even the basic example in the official coroutine samples uses AtomicInteger to count emits of parallel coroutines and says to use this if possible

atomic doesn't use synchronization blocks

sure but ConcurrentHashMap does

ConcurrentHashMap can't possibly have any suspend points while in the middle of a synchronized block