Does `Mutex.tryLock()` always return true? Or does it just not work like `ReentrantLock`?

# coroutines

[Ruckus]

Does Mutex.tryLock() always return true? Or does it just not work like ReentrantLock?

[elizarov]

Should not. It should return false if the mutex is taken and return.

[Ruckus]

Actually, I figured out I made a mistake, but it led to a confusing result.

suspend inline fun <T> Mutex.test(wait: Boolean, action: () -> T): T? {
    return if (tryLock()) {
        try {
            action()
        } finally {
            unlock()
        }
    } else {
        if (wait) withLock(action = action) else null
    }
}

suspend fun Mutex.demo(message: String, delay: Long = 3000L, wait: Boolean = false) {
    if (
        test(wait) {
            println("start: $message")
            Thread.sleep(delay)
            println("end: $message")
        } == null
    ) {
        println("skip: $message")
    }
}

fun main(args: Array<String>) = runBlocking<Unit> {
    val lock = Mutex()
    launch { lock.demo("A", wait = false) }
    delay(50)
    launch { lock.demo("B", wait = false) }
    delay(50)
    launch { lock.demo("C", wait = false) }
}

Notice the Thread.sleep() in demo(). If I replace it with a delay() it works as expected, but with Thread.sleep(), they all wait. Is that expected?

[Zach Klippenstein (he/him) [MOD]]

That sounds right - If you call Thread.sleep it blocks your thread, so the runBlocking event loop can't process any more events, so all your coroutines will block.

[Ruckus]

Ah, indeed. That makes perfect sense. Maybe I need to take a break for a bit.

[elizarov]

We’re actually planning an inspection to flag blocking calls like Thread.sleep inside coroutines. That would have helped to spot the problem

[Ruckus]

Indeed, that would be nice

[Dico]

I wonder when a programmer really intends to launch a coroutine with the thread used by runBlocking. I have seen it come up as the answer to questions by confused developers multiple times.

[uli]

@Dico what's wrong with launching something to the thread that sits in runBlocking?

[Dico]

I didn't claim that something is wrong with that. It's just an uncommon use case, which is easy to use by accident. If you have an outer CoroutineScope it will be shaded away completely by runBlocking which does not copy any of its context.

[Zach Klippenstein (he/him) [MOD]]

If you have an outer CoroutineScope, you should use something like withContext instead of calling runBlocking - because runBlocking is a blocking call, and making blocking calls from within a coroutine is discouraged.

The issue is the blocking call, not the fact that all coroutines happen to be dispatched to the same thread.

[Dico]

Yeah, it's not idiomatic. withContext does something completely different though and is irrelevant. I'm not looking for advice for a project, I just brought up an easy little pitfall that every programmer might eventually run into. I wrote an issue in kotlinx.coroutines the other day if you want it explained better. Just to make sure it's considered.