1. Why Asynchronous Programming? · Asynchronous Programming with Coroutines

[THEORY]

[PREDICT]

Read the code carefully before you run it.

prediction.kt

import kotlin.system.measureTimeMillis

fun loadProfile(): String {
    Thread.sleep(500)
    return "Profile loaded"
}

fun loadSettings(): String {
    Thread.sleep(500)
    return "Settings loaded"
}

fun main() {
    val duration = measureTimeMillis {
        println(loadProfile())
        println(loadSettings())
    }
    println("Total time: $duration ms")
}

loadProfile() and loadSettings() each block for 500ms. How long does the whole block take, roughly, and why?

[TASK]

An order system checks three things at checkout: the user profile, the cart and the stock level. Each check takes time (simulated with Thread.sleep). Add the missing function checkStockLevel (like the other two, with Thread.sleep(800) and return value true) and call all three checks one after another in the main block. Measure the total duration with measureTimeMillis and print it.

task.kt

import kotlin.system.measureTimeMillis fun checkProfile(): Boolean { Thread.sleep(300) return true } fun checkCart(): Boolean { Thread.sleep(500) return true } // TODO: fun checkStockLevel(): Boolean { ... } fun main() { val duration = measureTimeMillis { // TODO: call all three checks } println("Checkout check finished in $duration ms") }

Before you get a hint: what have you tried, and where exactly are you stuck?

[COMPREHENSION CHECK]

1. Why is an extra thread per slow operation not an infinitely scalable solution?

The JVM runs at most as many threads as there are CPU cores, so extra threads are rejected at startup Each thread needs its own memory and each context switch costs time, so their number is limited A waiting thread blocks the other threads of the same process, so the wait times add up anyway Threads do not share memory with each other, so results are lost when they are passed back to the caller

2. What is a central problem of callback-based asynchronous code?

The compiler cannot check the parameter types of a callback, so type errors only show up at runtime A callback blocks the calling thread until the result arrives, so the code is no faster than sequential code Nested callbacks produce deeply indented code, so error handling ends up scattered over many places Every callback runs on a new thread of its own, so memory use grows with each additional nesting level

3. Roughly how long does the measured block in the sample code take, and why?

About 1000ms, because both calls block the same thread one after the other and the wait times add up About 1000ms, because each function needs 500ms of CPU time to compute its result before it returns About 500ms, because the JVM runs both Thread.sleep calls on separate threads at the same time About 0ms, because measureTimeMillis counts only CPU time and Thread.sleep uses no CPU while it waits