Sequential processing places actions on one execution timeline so they occur in order, one after another. Actions on subsequent lines commonly follow this pattern, as can left-to-right argument evaluation. The distinction matters because other actions may run in parallel and complete in an unexpected order. section 15.22 section 17.8
Use timeline diagrams to reason about sequential processing:
- Identify every action, decomposing composite operations such as ++ and += into atomic reads and writes. section 15.22
- Draw sequential actions on the same timeline and parallel actions on separate timelines. section 15.22
- Simplify timelines by combining actions that cannot interleave and adding dotted lines for constrained ordering. section 15.22
- Compare possible orders as impossible, desirable, or undesirable before changing the implementation. section 15.22
Sequential requests and faster parallel work
Suppose cost_ajax() takes three seconds and shipping_ajax() takes four. Waiting for both responses sequentially takes seven seconds because the times add. Starting them in parallel takes four seconds, but responses can return out of order and produce faulty behavior. A coordination primitive can preserve the required order while retaining the speed benefit of parallel execution. section 17.8 section 17.13
Inspect the timeline figure to compare coordinated parallel work with sequential ordering and see where execution waits. section 17.13
