Multi-Threading

A running program is a process. The kernel tracks each one in a Process Control Block (PCB): its ID, its state, its memory, and — crucially — a saved copy of all the registers. With a single core, only one process runs at any instant. The illusion of “at the same time” comes from switching between them many times a second.

Context switching

To switch, the CPU saves its registers into the current PCB, then restores the next process's registers from its PCB. Press play and watch a register set get parked and another swapped in:

It isn't hand-waving — here's the real ARM64 routine the Linux kernel runs to do it. Save the callee-saved registers of the previous task, load the next task's, and ret straight into it:

// linux/arch/arm64/kernel/entry.S — switching AArch64 tasks
SYM_FUNC_START(cpu_switch_to)
    mov   x10, #THREAD_CPU_CONTEXT
    add   x8, x0, x10            // x0 = previous task
    mov   x9, sp
    stp   x19, x20, [x8], #16    // save callee-saved registers
    stp   x21, x22, [x8], #16
    // …x23–x28…
    stp   x29, x9,  [x8], #16
    str   lr, [x8]

    add   x8, x1, x10            // x1 = next task
    ldp   x19, x20, [x8], #16    // restore callee-saved registers
    // …
    ldr   lr, [x8]
    mov   sp, x9
    ret                          // returns into the *next* task
SYM_FUNC_END(cpu_switch_to)

Creating a process: fork()

fork() clones the current process whole — same code, same memory (copy-on-write), its own PCB. The twist: it returns twice. The child sees 0; the parent sees the child's PID. Press the button to fork:

And the truth: clone()

On Linux, fork() is really a thin wrapper over clone() — a system call that lets you choose precisely what to share with the new execution context:

int clone(
    int flags,             // what to SHARE with the parent
    void *child_stack,     // the new execution context's stack
    int *ptid,
    int *ctid,
    unsigned long newtls   // Thread-Local Storage descriptor
);

Share nothing and you get a process. Share the memory space, file descriptors and signal handlers — and keep the same PID — and you get a thread. A thread isn't a special primitive; it's just clone() with the right flags. This is literally how glibc spawns a pthread:

// glibc/nptl/pthread_create.c — how a thread is really born
const int clone_flags =
      CLONE_VM        // ← share the same memory space
    | CLONE_FS | CLONE_FILES | CLONE_SYSVSEM
    | CLONE_SIGHAND
    | CLONE_THREAD    // ← same PID: it's a thread, not a process
    | CLONE_SETTLS    // ← give it its own Thread-Local Storage
    | CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID;

__clone_internal(&args, &start_thread, pd);

You rarely create raw threads on Android. Instead, work is posted as messages onto a MessageQueue, ordered by when they're due. A Looper spins forever, pulling the next ready message and handing it to a Handler to run. Post a few — immediate and delayed — and watch the loop drain them in time order:

To turn any thread into a message-processing thread, you give it a Looper and loop it. That's the whole pattern:

class MyLooperThread {
    private var handler: Handler? = null

    init {
        Thread {
            Looper.prepare()                       // 1 — give this thread a Looper
            handler = Handler(Looper.myLooper()!!) // 2 — a Handler to post into it
            Looper.loop()                          // 3 — block & process forever
        }.start()
    }

    fun post(task: () -> Unit) = handler?.post(task)
    fun postDelayed(delay: Long, task: () -> Unit) =
        handler?.postDelayed(task, delay)

    fun stop() {
        handler?.post { Looper.myLooper()?.quit() }
        handler = null
    }
}

The Main Thread is just a Looper thread

There's nothing magic about the UI thread. It was prepared as a Looper thread before your app's code ran, and every touch, draw and callback is a message on its queue. Which is why this works from anywhere:

val mainHandler = Handler(Looper.getMainLooper())

mainHandler.post {
    println("Hello from the Main Thread!")
}

Synchronising with VSYNC

Animations can't just update whenever — they'd tear or waste frames. The Choreographer posts frame callbacks aligned to the display's VSYNC pulse (~16.6ms at 60Hz), and ValueAnimator computes its value once per pulse. One heartbeat drives every animation in sync:

A two-handed talk

Presented together

This was a joint session — built and delivered together, trading off between the low-level systems story and the high-level Kotlin one.

Take it further

Further reading