Transactional Memory Semaphores, monitors, and conditional critical regions all suffer from limitations based on lock semantics Naïve synchronization may be safe, but won’t scale Better performing approaches are necessarily more complex and risk hazards/deadlocks, whose absence is hard to prove Want to compose atomicity (locked code doesn’t compose) Transactional memory attempts to address this issue Similar to discrete event simulation: speculative execution Detect conflicts at run-time, arbitrate so one tx proceeds Other tx must abort and roll back to an earlier checkpoint Hopefully, most transactions can complete without rollback However, the extent to which that is true affects performance A key issue is that side-effects (I/O) may be hard to undo

Implicit Synchronization Implicit synchronization is done when (part of) one program construct waits until (part of) another is done E.g., parallel for loops in various languages run “multi-phase” E.g., perform a set reads for all expressions right hand sides and then perform a set of writes to assign left hand sides … Futures (and promises and tasks, etc.) offer explicit language constructs for implicit synchronization In C++11, can use std::promise and std::future for asynchronous delivery of a result from one thread to another The program doesn’t say how to wait (encapsulated by the promise/future mechanism) only that result will appear later

And-Parallelism and Or-Parallelism And-parallelism requires all results to be produced Parent thread (or process) waits for children to complete Often, uses their results to compute another result Or-parallelism requires only one result to be produced May take the first, or select from ones available at a deadline Raises important scheduling issues, e.g., liveness, fairness And-parallelism and or-parallelism are often important in non-imperative (e.g., logic, functional) languages E.g., in Lisp, and-parallel evaluation of sub-expressions E.g., in Prolog, or-parallelism and backtracking in resolution Other approaches used in non-imperative languages E.g., Erlang’s message passing between client, server code

Message Passing Implemented via two operations, send and receive Gives another higher-level construct for concurrency control, this time based on similar semantics to distributed processes Also often implemented as objects (Active Object Pattern) Synchronization of sender and receiver may vary Sender may wait for receiver, or drop off message (buffered) Receiver may block or continue if no messages are available May also involve an intermediary (mailbox, event channel) and push/push, push/pull, pull/push, or pull/pull operations Ada task rendezvous as an example within a language An accept statement matches entries with code to run Separate caller (sender) and called (receiver) threads wait for each other (rendezvous) before continuing

Today’s Studio Exercises We’ll code up ideas from Scott Chapter 12.4.4 to 12.6 Again via C++11 concurrency/synchronization types/features Looking at additional concurrency/synchronization ideas Today’s exercises are again in C++ Please take advantage of the on-line tutorial and reference manual pages that are linked on the course web site The provided Makefile also may be helpful As always, please ask us for help as needed When done, send email with your answers to the cse425@seas.wustl.edu account, with subject line “Concurrency Studio IV”