Chapter 16: Sharing resources between timelines
The introduction explains why timelines sometimes need to share resources safely, while previewing the chapter’s approach.
After this chapter you will be able to
- Safe resource sharing between timelines. Explain why avoiding shared resources is ideal for timelines but is not always possible, and why any necessary sharing must be safe.
- Coordinating shared resources. Explain why timelines that must share a resource need coordination and what coordination accomplishes.
- Shared DOM update ordering. Explain why the order of the two shopping-cart DOM updates matters, even when the user adds the same items in the same order.
- DOM update ordering problem. Explain why DOM updates from separate click timelines may not occur in click order, even though the clicks themselves have an order.
- Queue for ordered updates. Describe how a queue coordinates DOM updates across timelines so they follow click order.
- Click Handler Work Boundary. Explain why the click handler keeps the work before cost_ajax() and puts the remaining cart-update work on the queue.
- Single Worker Queue Flow. Trace how the queue accepts clicks and processes their items one at a time, in order, until it is empty.
- Asynchronous Completion Callback. Explain why the queue starts the next task from calc_cart_total()’s callback rather than from the next line after calling it.
- Real-world models for sharing. Explain why programs need explicit rules for sharing resources and how real-world arrangements can inspire those rules.
- Generic queue worker. Explain how extracting done() and passing a worker into Queue() separates the queue’s control flow from shopping-cart-specific work.
- Ordered timeline execution. Explain what new ordering guarantee Queue() gives an action and why the section calls it a concurrency primitive.
- Shared resource ordering analysis. Explain why timeline analysis compares actions that use the same resource, and describe why the cart accesses cannot get out of order.
- Queued DOM update order. Explain why placing the DOM updates in a queue makes their order predictable.
- Queue operation ordering. Describe how the section checks the queue shared across three timelines and why the remaining uncertain ordering is acceptable.
- Timeline diagram problem analysis. Explain how a timeline diagram can reveal shared resources and actions that might occur in the wrong order, and why drawing one is worthwhile when programming actions.
- Dropping queue behavior. Explain why the cart’s total-update queue can discard pending work and what that changes for the user.
- Ordered DOM Updates. Explain that sharing the DOM between timelines caused an ordering problem, and that a queue solved it.
What it builds on
- Timelines that share resources can cause problems (chapter 15) · Timelines that share resources can cause problems.
- Asynchronous calls require new timelines (chapter 15) · Asynchronous calls create timelines whose ordering needs attention.
- Principle: In an asynchronous context, we use a final callback instead of a return value as our explicit output (chapter 15) · An asynchronous operation uses a final callback instead of a return value as its explicit output.
- Converting a global variable to a local one (chapter 15) · Moving a global variable into local scope limits its reach.
- Actions, calculations, and data (chapter 3) · The distinction between actions and calculations.
- Timeline diagrams side-by-side can reveal problems (chapter 15) · Timeline diagrams can reveal problems across timelines.
Section by section
Introduction
The introduction explains why timelines sometimes need to share resources safely, while previewing the chapter’s approach.
- Safe resource sharing between timelines: Explain why avoiding shared resources is ideal for timelines but is not always possible, and why any necessary sharing must be safe.
Why it matters: This is the problem the chapter’s resource-sharing techniques address.
Key terms: timelines, resources, share resources
16.1 Principles of working with timelines
This section explains why simpler timelines are easier to analyze and why timelines must coordinate when they share resources.
- Reducing possible timeline orderings: Explain how having fewer timelines, fewer steps in each timeline, and fewer resources shared across timelines makes concurrent behavior easier to understand.
Why it matters: Simplifying timelines makes it easier to see which orderings could cause trouble. - Coordinating shared resources: Explain why timelines that must share a resource need coordination and what coordination accomplishes.
Why it matters: Coordination helps prevent incorrect results when timelines cannot avoid using the same resource.
Key terms: timelines, steps, shared resources, possible orderings, coordinate, take turns
16.2 The shopping cart still has a bug
The section shows why two shopping-cart timelines that update the shared DOM can produce different results depending on their order.
- Shared DOM update ordering: Explain why the order of the two shopping-cart DOM updates matters, even when the user adds the same items in the same order.
Why it matters: Shared resources make timing relevant to whether the cart displays the right result.
Key terms: timelines, shared DOM resource, DOM updates, possible orderings
16.3 We need to guarantee the order of the DOM updates
Explains why asynchronous DOM updates may arrive out of click order and how a queue can preserve that order.
- DOM update ordering problem: Explain why DOM updates from separate click timelines may not occur in click order, even though the clicks themselves have an order.
Why it matters: Click order alone cannot protect the DOM from an out-of-order update. - Queue for ordered updates: Describe how a queue coordinates DOM updates across timelines so they follow click order.
Why it matters: The queue gives otherwise independent timelines an ordering rule for their DOM work. - Problematic shared resources: Distinguish the examples of shared resources that can cause timeline problems from calculations and immutable values.
Why it matters: Recognizing which shared resources may cause trouble helps you spot where timeline coordination is needed.
Key terms: timelines, DOM updates, network request, queue, shared resource, timeline, shared resources, global variables, DOM, shared local variables
16.4 Building a queue in JavaScript
The section builds a JavaScript queue that processes cart updates in click order across asynchronous timelines, then contains the queue’s mutable state.
- Click Handler Work Boundary: Explain why the click handler keeps the work before cost_ajax() and puts the remaining cart-update work on the queue.
Why it matters: Choosing the boundary identifies which work needs ordering across clicks. - Single Worker Queue Flow: Trace how the queue accepts clicks and processes their items one at a time, in order, until it is empty.
Why it matters: These pieces together let fast clicks finish in the order they arrived. - Asynchronous Completion Callback: Explain why the queue starts the next task from calc_cart_total()’s callback rather than from the next line after calling it.
Why it matters: Advancing too early would defeat the queue’s one-item-at-a-time ordering. - Scoped Queue State: Describe why Queue() encloses the queue variables and helper functions and returns update_total_queue().
Why it matters: Containing the mutable state makes the shared queue safer to use from other timelines. - Controlled Mutation In Functional Thinking: Justify the queue’s mutable state using the section’s account of functional programming and actions.
Why it matters: The aim is predictable shared actions, not avoiding every mutable value.
Key terms: click handler, cost_ajax(), calc_cart_total(), queue, queue_items, shift(), working, runNext(), callback, Queue()
16.5 Principle: Use real-world sharing as inspiration
The section explains why sharing resources must be programmed explicitly and suggests using familiar real-world sharing arrangements as inspiration.
- Real-world models for sharing: Explain why programs need explicit rules for sharing resources and how real-world arrangements can inspire those rules.
Why it matters: Everyday sharing arrangements offer a starting point when you need to design a shareable resource. - Queue tradeoffs and alternatives: Distinguish queues from the other real-world sharing arrangements named here, including the downside of waiting in a queue.
Why it matters: A queue is one possible model, not the answer to every sharing problem.
Key terms: share resources, queue, queues, locks, book pools, blackboards
16.6 Making the queue reusable
This section turns the shopping-cart queue into a reusable way to run tasks in order and call back when each task finishes.
- Generic queue worker: Explain how extracting done() and passing a worker into Queue() separates the queue’s control flow from shopping-cart-specific work.
Why it matters: Separating scheduling from task-specific work lets the same queue serve other operations. - Per-task completion callbacks: Describe how the queue accepts a callback for each task and makes it possible to call that callback when the task is done.
Why it matters: A completion callback lets the caller’s timeline continue after its queued task finishes. - Ordered timeline execution: Explain what new ordering guarantee Queue() gives an action and why the section calls it a concurrency primitive.
Why it matters: Restricting possible orderings makes shared-resource actions run predictably.
Key terms: done(), worker(), Queue(), runNext(), replace body with callback, callback, item.data, higher-order function, concurrency primitive, linearize()
16.7 Analyzing the timeline
The section uses a timeline diagram to check whether the shopping cart, DOM, and queue remain correct when multiple clicks create overlapping timelines.
- Shared resource ordering analysis: Explain why timeline analysis compares actions that use the same resource, and describe why the cart accesses cannot get out of order.
Why it matters: Checking only relevant orderings makes a complex timeline easier to reason about. - Queued DOM update order: Explain why placing the DOM updates in a queue makes their order predictable.
Why it matters: It explains why the queue fixes the DOM ordering problem that prompted its creation. - Queue operation ordering: Describe how the section checks the queue shared across three timelines and why the remaining uncertain ordering is acceptable.
Why it matters: A shared queue need not have every operation ordered in advance if every possible remaining order is correct.
Key terms: shared resources, cart global variable, dotted line, DOM updates, queue, single timeline, dotted lines, queue concurrency primitive
16.8 Principle: Analyze the timeline diagram to know if there will be problems
This section explains why drawing and analyzing timeline diagrams helps reveal timing problems that tests may miss.
- Timeline diagram problem analysis: Explain how a timeline diagram can reveal shared resources and actions that might occur in the wrong order, and why drawing one is worthwhile when programming actions.
Why it matters: A diagram can expose a timing bug before an unlikely ordering occurs for a real user.
Key terms: timeline diagrams, shared resources, possible orderings, timing bugs
16.9 Making the queue skip
This section explains how a dropping queue avoids processing obsolete pending updates while preserving the task already in progress.
- Dropping queue behavior: Explain why the cart’s total-update queue can discard pending work and what that changes for the user.
Why it matters: Discarding updates that would immediately be overwritten lets the user see the current total sooner.
Key terms: dropping queue, update_total_queue, unprocessed item
16.10 Conclusion
The chapter concludes that an ordering problem in shared DOM updates was solved with a reusable queue.
- Ordered DOM Updates: Explain that sharing the DOM between timelines caused an ordering problem, and that a queue solved it.
Why it matters: The queue addresses the ordering requirement for updates to a shared resource. - Reusable Higher-Order Queue: Describe the resulting queue as a highly reusable higher-order function.
Why it matters: The solution was useful beyond the immediate DOM-update problem.
Key terms: resource-sharing issue, DOM, queue, higher-order function
16.11 Summary
16.12 Up next…
Recaps the chapter’s work on resource-sharing issues and previews coordinating timelines in the next chapter.
Where this is used later
- Principles of working with timelines (chapter 17) · The need to guarantee an order for updates
- Possible ordering analysis (chapter 17) · Analyzing possible orderings relies on using a timeline diagram to spot timing problems.
Concepts explained in this chapter
- queueA book-specific JavaScript function that creates an encapsulated queue and returns an operation for submitting work to it.
- concurrency primitiveA synchronization construct that provides a defined operation for coordinating concurrent execution paths or managing shared resources.
- extract function argument refactoringA refactoring technique that converts information encoded implicitly in a function name or surrounding code into an explicit function argument.
- DOM updateA modification to the Document Object Model that changes a document's represented content, structure, or presentation.
- scopeThe region of a program in which a binding can be accessed or referenced.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.