Concurrency

Intent Monitor pattern is used to create thread-safe objects and prevent conflicts between threads in concurrent applications. Explanation In plain words Monitor pattern is used to enforce single-threaded access to data. Only one thread at a time is allowed to execute code within the monitor object. Wikipedia says In concurrent programming (also known as parallel programming), a monitor is a synchronization construct that allows threads to have both mutual exclusion and the ability to wait (block) for a certain condition to become false.

Intent Producer Consumer Design pattern is a classic concurrency pattern which reduces coupling between Producer and Consumer by separating Identification of work with Execution of Work. Explanation Real-world example Consider a manufacturing process of item, the producer will need to pause the production when manufacturing pipeline is full and the consumer will need to pause the consumption of item when the manufacturing pipeline is empty. We can separate the process of production and consumption which work together and pause at separate times.

Also known as CompletableFuture Intent A Promise represents a proxy for a value not necessarily known when the promise is created. It allows you to associate dependent promises to an asynchronous action’s eventual success value or failure reason. Promises are a way to write async code that still appears as though it is executing in a synchronous way. Explanation The Promise object is used for asynchronous computations. A Promise represents an operation that hasn’t completed yet, but is expected in the future.

Intent The Reactor design pattern handles service requests that are delivered concurrently to an application by one or more clients. The application can register specific handlers for processing which are called by reactor on specific events. Dispatching of event handlers is performed by an initiation dispatcher, which manages the registered event handlers. Demultiplexing of service requests is performed by a synchronous event demultiplexer. Class diagram Applicability Use Reactor pattern when

Intent Regular lock does not distinguish the ‘read lock’ and ‘write lock’, as when access the data structure patterns consists of many threads reading the data, each thread will have to lock it which produces unnecessary serialization. The existence of reader-writer lock resolves this issue as it is well known as “multiple concurrent readers, single writer locks”, used to consist of multiple threads reading the data concurrently and allow only one thread to write or modify the data.

Intent It is often the case that tasks to be executed are short-lived and the number of tasks is large. Creating a new thread for each task would make the system spend more time creating and destroying the threads than executing the actual tasks. Thread Pool solves this problem by reusing existing threads and eliminating the latency of creating new threads. Explanation Real-world example We have a large number of relatively short tasks at hand.

Intent Provide an ability to have a copy of a variable for each thread, making it thread-safe. Explanation During code assembling compiler add .tdata directive, which means that variables below will store in different places from thread to thread. This means changing variable in one thread won’t affect the same variable in other thread. Real world example On constructions each worker has its own shovel. When one of them broke his shovel, other still can continue work due to they have own instrument.

Name / classification Version Number. Also known as Entity Versioning, Optimistic Locking. Intent Resolve concurrency conflicts when multiple clients are trying to update same entity simultaneously. Explanation Real world example Alice and Bob are working on the book, which stored in the database. Our heroes are making changes simultaneously, and we need some mechanism to prevent them from overwriting each other. In plain words Version Number pattern grants protection against concurrent updates to same entity.

Intent Used to handle all problems that can be encountered when doing distributed transactions. Class diagram Applicability This pattern can be used when we need to make commits into 2 (or more) databases to complete transaction, which cannot be done atomically and can thereby create problems. Explanation Handling distributed transactions can be tricky, but if we choose to not handle it carefully, there could be unwanted consequences. Say, we have an e-commerce website which has a Payment microservice and a Shipping microservice.