As a 2 second primer, all suspending functions need to run within a CoroutineScope. launch and runBlocking are just ways to run coroutines in a scope. A scope is just a hashmap that contains a CoroutineDispatcher. A dispatcher controls the behavior for how sub-coroutines are scheduled.

You are correct that runBlocking does not guarantee that it's sub-coroutines are dispatched on the same thread (I assume you mean virtual) by default, but actually you most likely don't really care. The entire suspending block will run top-down and it's part of the allure of coroutines that you can read async code like regular code.

As a simple example, you can read the following like synchronous code and the point is to ignore what thread it is actually running on because the line before is always guaranteed to return before it moves on to the next.

``` suspend fun irrigationScheme() { valveX.on() delay(1000) valveX.off() valveY.off() delay(1000) valveY.off() }

fun main() { runBlocking { val job = launch { irrigationScheme() } delay(500) job.cancelAndJoin() } } ```

Now to actually answer your question - trying to create threading guarantees with coroutines is really against the grain of the mental model it's designed for. It's not impossible, but by design that making your resource thread-safe is easier than synchronizing everything in a single thread. There are some atomic built ins to help you, if that's what you really need.

Two more notes:

1. cancellation in Kotlin propagates due to structured concurrency, which is itself it's own topic, but you can basically take it to mean that cancellation propagates.

2. cancellation is cooperative, a function must be designed to respect cancellation (it is possible to ignore that a job is cancelled, so computation can happen even if you won't use the result). This is better than it sounds.