✳flâneur — a map of the web's best reading

Reading 16: Mutual Exclusion

web.mit.edu · 6,062 words · saved by 2 readers

This reading brings together the ideas of concurrency and promises, in the context of an asynchronous abstract data type – an ADT with asynchronous operations that might run concurrently with each other, accessing the same shared (mutable) rep. We will see how this raises the risk of concurrency bugs, such as race conditions and deadlocks, which threaten the invariants and specifications that the ADT is striving to guarantee. By reasoning about interleaving of concurrent code, and taking advantage of mutual exclusion (periods when code is running by itself without interleaving), we can defend against those bugs. As a running example, let’s think about a library that allows users to borrow and return books. First, we’ll need some types to represent books and users: The operations have been omitted, because we won’t be calling any operations on users or books, just using them for their identity. Here is the library, and its two key operations checkout and checkin: This initial spec for c

Reading 16: Mutual Exclusion Reading 16: Mutual Exclusion Software in 6.102 Safe from bugs Easy to understand Ready for change Correct today and correct in the unknown future. Communicating clearly with future programmers, including future you. Designed to accommodate change without rewriting. Objectives This reading brings together the ideas of concurrency and promises, in the context of an asynchronous abstract data type – an ADT with asynchronous operations that might run concurrently with each other, accessing the same shared (mutable) rep. We will see how this raises the risk of concurren

Explore this link on the map →

saved by

related reading