If you are a bit familiar with , you probably already have the idea that coroutines are a mechanism that runs a set of instructions. You’ve probably also heard the term or . In broad terms, this means that are that cooperatively execute a set of instructions and that the operating system doesn't control the scheduling of tasks or processes performed by coroutines. Instead, it relies on the program, and platform that runs them to do that. As such, coroutines can yield control back to the scheduler to allow other threads to run. This is particularly useful for operations where we need to wait for certain operations—a query to a database or a request to the website—to be completed. Being means that while we wait, the scheduler can execute other segments of coroutines. This is what I talk about in this post with a focus on the interesting properties that coroutines have of running concurrently. If they run on a single Thread and are released at the same time, we won't be able to predict the order in which they execute. coroutines cooperative multitasking non-preemptive multitasking coroutines concurrency primitives REST cooperative I have a simple example of this phenomenon available on my implemented with . GitHub repository Kotlin Here is how to use it from the command line: git clone https://github.com/jesperancinha/jeorg-kotlin-test-drives.git
cd jeorg-kotlin-coroutines/coroutines-crums-group-1
make b The executable class is SimpleConcurrency in Kotlin: class SimpleConcurrency {
   companion object {
       /**
        * This test runs sleep with the purpose to show concurrency in coroutines
        */
       @JvmStatic
       fun main(args: Array<String> = emptyArray()) = runBlocking {
           val timeToRun = measureTimeMillis {
               val coroutine1 = async {
                   delay(Duration.ofMillis(nextLong(100)))
                   async {
                       val randomTime = nextLong(500)
                       sleep(Duration.ofMillis(randomTime))
                       println("Coroutine 1 is complete in $randomTime!")
                   }.await()
               }
               val coroutine2 =
                   async {
                       delay(Duration.ofMillis(nextLong(100)))
                       async {
                           val randomTime = nextLong(500)
                           sleep(Duration.ofMillis(randomTime))
                           println("Coroutine 2 is complete in $randomTime!")
                       }.await()
                   }
               coroutine2.await()
               coroutine1.await()
           }
           println("Time to run is $timeToRun milliseconds")
       }
   }
} If you run this class multiple times, the result will be different: Coroutine 2 is complete in 342!
Coroutine 1 is complete in 389!
Time to run is 805 milliseconds! or Coroutine 1 is complete in 291!
Coroutine 2 is complete in 140!
Time to run is 516 milliseconds The code looks complicated but although this seems an easy problem to exemplify, working with coroutines can be quite challenging as when we look at the details it starts to look very confusing. For example, how would I be able to test the random start of the coroutines? To start off, I need a blocking scope because I want the to run in a single Thread and I achieve that with . Then I want to make sure they start at random times. However, the control may be random, if I would just start using a sequential and imperative type of code, the second asynchronous declared would always start later on than the first. This is why I first launch two coroutines with and then randomly delay them. This way I make sure that they will start at random times just like a real case. For both of these, I then start a sub-coroutine, where I, instead of using delay, use the blocking sleep function. This is to ensure that the first coroutine that sleeps will then block the other. If we observe our result, we do see that they start in random order and that the sum of their execution times matches the total execution time of the program proving that they concurrently try to gain control of a Thread. In real cases, we do not use and there are multiple threads involved to share with these called . This is here only to exemplify that. coroutines runBlocking coroutines coroutine async runBlocking concurrency primitives coroutines More on this in this video: https://youtube.com/shorts/JdleGvk8Xj8?feature=share&embedable=true Also published . here

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

How Coroutines Enable Cooperative Multitasking and Concurrency

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Can You Apply Reactive Programming to Legacy Services? This WebFlux Example Says You Can

Turning the Compiler Into Your Co-Architect

Inside Go Channels: Buffers, Locks, and the Runtime Memory Model

Go Concurrency Face-Off: Channels vs Mutexes

Streamlining Go Concurrency Using a Worker Pool

A Guide to OpenTelemetry Tracing for the JVM

Can You Apply Reactive Programming to Legacy Services? This WebFlux Example Says You Can

Turning the Compiler Into Your Co-Architect

Inside Go Channels: Buffers, Locks, and the Runtime Memory Model

Go Concurrency Face-Off: Channels vs Mutexes

Streamlining Go Concurrency Using a Worker Pool

A Guide to OpenTelemetry Tracing for the JVM

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps