Coordinated Conditional Output

The setup

This is the classic FizzBuzz exercise, but multithreaded. It shows up on LeetCode as "Fizz Buzz Multithreaded". The single-threaded version is a beginner exercise: count from 1 to n, and for each number print one of four things based on what divides it:

• If the number is a multiple of 15, print "fizzbuzz".
• Otherwise, if it is a multiple of 3, print "fizz".
• Otherwise, if it is a multiple of 5, print "buzz".
• Otherwise, print the number itself.

So for n = 15 the output is: 1 2 fizz 4 buzz fizz 7 8 fizz buzz 11 fizz 13 14 fizzbuzz.

The multithreaded twist: there are now four separate threads, each one in charge of exactly one of the four cases. They are running at the same time. The job is to make sure that for every number from 1 to n, only the right thread prints, the others stay quiet, and the output still comes out in the correct order.

A picture of one round

Imagine a small dispatcher in the middle of the room. For each number from 1 to n, the dispatcher looks at the number, decides which of the four threads should handle it, and gives only that thread the green light. The other three stay asleep for this round.

The dispatcher only wakes one thread per round. That thread does its print, signals back "done", and the dispatcher moves on to the next number.

Two ways to write this

The same idea has two common shapes in code, and which one you reach for depends on how the problem is framed.

Shape 1: a dispatcher with one signal per thread

This is what the diagram above shows. Set up four signals, one per thread. The dispatcher loops from 1 to n and uses an if/else chain on the divisibility rules to decide which signal to fire.

Each worker thread sits in a loop: wait on its own signal, print, signal back to the dispatcher that it is done. The dispatcher waits for "done" before moving to the next number, so the output stays in order.

This is what the Java semaphore code and the Go channel code above show. It is fast and easy to reason about because the routing logic lives in one place.

Shape 2: a single shared signal, each thread checks its own rule

A different way: skip the dispatcher. Have one shared counter and one shared signal. Every time the counter changes, the signal is broadcast to all four threads. Each thread wakes up, checks "is this number mine?", and either prints or goes back to sleep.

This is what the Python condition-variable code shows. It scales better when there are many rules (you do not have to hard-code an if/else chain in a dispatcher), but it wastes some work because every thread wakes up on every number.

Why the broadcast version needs a while, not an if

In the broadcast version every thread wakes up every round. So when a thread wakes, it has to ask itself "is the current number actually mine, or did the dispatcher just bump it for someone else?". That question has to be inside a while loop, not an if. Otherwise the thread might print on a wake-up that was meant for somebody else.

This is why the Python code reads while not (predicate): cv.wait(). The thread wakes, checks, and if the answer is "not me", goes back to sleep.

Where this pattern shows up in real systems

The shape of the problem ("look at this thing, decide which handler should run, wake only that handler") is everywhere:

• Message routing in Kafka, RabbitMQ, or any message broker. A message of type X gets delivered only to consumers subscribed to type X.
• Event dispatchers in GUI frameworks. A click event goes to the click handler; a key event goes to the key handler.
• In-process pub/sub. One publisher, many subscribers, each interested in a different topic.
• Workflow orchestrators. A task tagged "image-processing" goes to the image worker pool, not to the email worker pool.

Once you have written the dispatcher shape for FizzBuzz, all of these are the same code with different routing rules.