Creating and Starting Threads

diagram start() runs it elsewhere; run() just calls it mermaid

  flowchart TD
  A["t = Thread(target=work)"] --> B{"how do you launch it?"}
  B -->|"t.start()"| C["the OS creates a thread"]
  C --> D["run() is invoked THERE"]
  D --> E["work() executes on Thread-1"]
  B -->|"t.run()"| F["an ordinary method call"]
  F --> G["work() executes on the CALLING thread"]
  G --> H["fully sequential -- and it looks like it worked"]
  E --> I["t.join() waits for it"]
  I --> J["t.is_alive() is False afterwards"]
  J --> K["t.start() again -> RuntimeError: threads can only be started once"]

Thread.run is the ordinary method holding your target. Calling it yourself executes the body on whatever thread you called it from, which means no concurrency at all and no error to tell you. start() is the one that asks the operating system for a thread and then invokes run there.

run() instead of start() silently removes the concurrency

Verified by asking each target which thread it was on:

Launched with	current_thread().name
t.start()	Thread-1 (work)
t.run()	MainThread

No exception, no warning. The program still produces the right output — just one job at a time, which is why this survives review and shows up later as “threading made no difference”.

Two related facts, both measured:

• A thread cannot be restarted. Calling start() on one that has finished raises RuntimeError: threads can only be started once. Make a new Thread object per run.
• is_alive() is False after join(), which is the reliable way to check completion — not the absence of output.

Basic Thread usage

basic_thread.py

import threading
 
 
def greet(name: str) -> None:
    print("Hello", name)
 
 
t = threading.Thread(target=greet, args=("Ravi",))
t.start()
t.join()
print("Main thread finished")

Naming threads

Naming is helpful for logs.

thread_name.py

import threading
 
 
def work():
    print("Running in:", threading.current_thread().name)
 
 
t = threading.Thread(target=work, name="worker-1")
t.start()
t.join()

Common mistakes

1) Forgetting join()

If you don’t join(), the main program may exit early in some cases.

2) Sharing data without protection

Threads share memory. You need locks (next pages).

sketch start() puts the work elsewhere; run() does not p5.js Pause Restart

Two launches of the same target, which reports the thread it is executing on. With start() the work lands on a new thread and the main thread carries on immediately. With run() it is an ordinary method call, so the body executes on the caller and main waits for it -- no error, no warning, and no concurrency.

Check yourself

pch.quizTag pch.quizDefaultTitle

1. You call `t.run()` instead of `t.start()`. What happens?

   A RuntimeError B The target runs on the calling thread — no concurrency, no error C The target never runs D It runs on a new thread anyway
   pch.quizShowAnswer

   B — The target runs on the calling thread — no concurrency, no error — Verified by asking the target which thread it was on: `start()` reported `Thread-1`, `run()` reported `MainThread`. Nothing raises, so the program looks correct and is simply sequential.

2. What does calling `start()` on a thread that has already finished do?

   A Runs it again B Nothing C Raises RuntimeError: threads can only be started once D Blocks forever
   pch.quizShowAnswer

   C — Raises RuntimeError: threads can only be started once — Verified. A Thread object is single-use — create a new one per run.

3. How do you reliably know a worker thread has finished?

   A Check that it printed something B Call `t.join()`, then `t.is_alive()` is False C Sleep long enough D Call `t.stop()`
   pch.quizShowAnswer

   B — Call `t.join()`, then `t.is_alive()` is False — `join()` waits; `is_alive()` confirms. There is no `stop()` — a thread must be asked to finish, usually by checking a `threading.Event`.

4. Why does threading often fail to speed up CPU-bound Python?

   A Threads are not real OS threads B The GIL lets only one thread run Python bytecode at a time C Thread creation is too slow D Python threads are cooperative
   pch.quizShowAnswer

   B — The GIL lets only one thread run Python bytecode at a time — Measured elsewhere in this course: CPU-bound work on a 4-thread pool came out at 0.92x — slower than sequential. I/O-bound work on the same pool reached 9.2x, because a waiting thread releases the GIL.

🧪 Try It Yourself

Exercise 1 – Create a Simple Thread

pch.exerciseTag pch.exerciseTitle

Exercise 2 – Join a Thread

pch.exerciseTag pch.exerciseTitle

Exercise 3 – Run Multiple Threads

pch.exerciseTag pch.exerciseTitle