---
title: "Message Passing and Asynchronous Work"
description: "A message-passing counter can have one owner that applies queued updates one at a time. This removes shared-counter races, but queue capacity, overload, ordering and blocking still need design. Asynch"
canonical: https://lightmysky.com/learn/computing/message-passing-and-asynchronous-work-mt_twcpO-945r
source: https://lightmysky.com/learn/computing/message-passing-and-asynchronous-work-mt_twcpO-945r.md
retrieved: 2026-11-12
---

> **Agent view.** This is the Markdown twin of the page, for tools and assistants.
> When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md
> API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md
> Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt
> Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json
> Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`.

# Message Passing and Asynchronous Work

A message-passing counter can have one owner that applies queued updates one at a time. This removes shared-counter races, but queue capacity, overload, ordering and blocking still need design. Asynchronous requests let callers continue before a result is ready.

Subject: Computing · Area: Computer Systems · Ages 21 to 22
Page: https://lightmysky.com/learn/computing/message-passing-and-asynchronous-work-mt_twcpO-945r

## Ready when they can

- Rewrite a lock-based counter as a single owner served by a message queue
- Say what a bounded queue does when the producer outruns the consumer
- Compare the failure modes of shared memory and of message passing

## Lesson: Do not share, just send word

You have seen races and deadlocks with shared counters and locks. In this message-passing design, one worker owns the counter. Other workers send update messages; they never read or write the counter directly. The owner finishes one update before starting the next, so updates do not interleave. Starting at 0, it handles add 1, add 1, then add 2 to reach 4. The counter needs no lock between senders, though the queue still needs safe concurrent access.

*(drawing: The owner completes each update before handling the next message. Other workers only send messages.)*

Bounded queues have fixed capacity. Full-queue policy blocks sends, rejects them or drops messages. Back pressure blocks or slows producers; dropping alone does not. Sustained overload needs fewer arrivals or faster processing. Extra capacity absorbs finite bursts, not a lasting rate gap. Unbounded queues can exhaust memory.

**Example.** With constant rates, an empty queue, enough space and no drops, subtract the number handled from arrivals each second. Multiply that gain by elapsed seconds. If 6 arrive and 4 are handled each second, after 2 seconds: (6 - 4) × 2 = 4 queued.

FIFO removes messages in enqueue order, not necessarily the application's required order. Starting one producer first does not determine which send arrives first. Separate FIFO queues need a merge rule. If a coordinator requires A before B, it can enqueue both in that order.

Asynchronous requests let callers continue before completion. Replies may arrive out of order or never arrive. Match replies by request ID and define a missing-reply policy, such as a timeout. Asynchronous calling does not speed up the work or require the owner to handle messages concurrently.

Serial ownership removes sender races on this counter. Shared state needs coordination; locks can deadlock. Messages can be lost, misordered or blocked by full queues. Two workers blocking on full outgoing queues instead of receiving can deadlock.

**Recap.** One serial owner removes races on its counter. Define queue limits, overload policy and required order. For asynchronous requests, match replies to requests and handle failure.

*Original lesson, questions and flashcards about single-owner message passing and asynchronous requests, authored for this dataset.*

## Practice

8 questions on this page, each with its working shown.

## Needs first

- [Deadlock and the Four Conditions](https://lightmysky.com/learn/computing/deadlock-and-the-four-conditions-mt_CsMOA4sBb1)

## Optional connections

- [Queues: First In, First Out](https://lightmysky.com/learn/computing/queues-first-in-first-out-mt_4U1bT0JW4g)

## Opens up

- [Training Across Many Devices: Data, Model and Pipeline Parallelism](https://lightmysky.com/learn/computing/training-across-many-devices-data-model-and-pipeline-parallelism-mt__e-JwIxHek)
- [Data Pipelines: Batch, Streaming and Doing It Twice](https://lightmysky.com/learn/computing/data-pipelines-batch-streaming-and-doing-it-twice-mt_o0zBEPLbmF)