Hubbry Logo
Concurrency patternConcurrency patternMain
Open search
Concurrency pattern
Community hub
Concurrency pattern
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Concurrency pattern
Concurrency pattern
Concurrency pattern
View on Wikipedia
from Wikipedia

A concurrency pattern is a software design pattern that supports concurrent processing.

Examples

[edit]

Examples include:

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Concurrency pattern

View on Grokipedia
from Grokipedia
Concurrency patterns are design solutions that address recurring challenges in concurrent programming, such as coordinating multiple threads or processes to share resources safely and efficiently in multi-threaded software systems. These patterns provide reusable architectural and behavioral structures to manage , resource access, and execution flow, enabling developers to build scalable, performant applications without reinventing solutions for common concurrency issues like race conditions or deadlocks. In , concurrency patterns emerged as an extension of the broader paradigm introduced in the , specifically tailored for distributed and multi-threaded environments where parallelism is essential for handling high loads or real-time demands. They are particularly vital in domains like networking , real-time systems, and , where improper concurrency management can lead to inefficiencies or failures. Key benefits include decoupling invocation from execution to simplify , optimizing thread usage to minimize overhead, and ensuring through mechanisms like monitors or locks. Notable concurrency patterns include the pattern, which decouples method invocation from execution by queuing requests in a separate thread; the Monitor Object pattern, which serializes access to an object's methods using a single lock for ; and the Half-Sync/Half-Async pattern, which separates asynchronous input processing from synchronous computation via a queuing layer to balance responsiveness and structure. Other influential patterns encompass Leader/Followers, where threads dynamically rotate roles to handle events without dedicated demultiplexing threads, and Thread-Specific Storage, which allows per-thread data access without global locking. For resource sharing, patterns like sequence tasks to process requests through resources in a , while Shared Resource uses protected units for exclusive access by multiple tasks. These patterns, often combined with synchronization primitives, form the foundation for reliable concurrent systems across languages like , C++, and Go.

Overview

Definition

Concurrency patterns are reusable solutions to commonly occurring problems in concurrent programming, where multiple threads or processes execute simultaneously to coordinate access to shared resources and avoid issues such as race conditions and deadlocks. These patterns focus on efficient resource sharing, , and communication in multi-threaded environments, providing high-level abstractions that handle shared data access without delving into low-level implementation details. Key characteristics of concurrency patterns include their emphasis on partitioning work among threads, managing inter-thread communication via mechanisms like queues, and ensuring thread-safe operations through synchronization primitives such as locks. Unlike general in sequential programming, which primarily address object structure and behavior in single-threaded contexts, concurrency patterns incorporate parallelism-specific elements to resolve issues arising from simultaneous execution. In relation to the Gang of Four (GoF) design patterns, which are oriented toward sequential object-oriented software, concurrency patterns extend these concepts by integrating concurrency controls like monitors and reactors to handle multi-threaded scenarios effectively. Concurrency patterns emerged in the 1990s amid the growing adoption of multi-threaded and networked systems, driven by demands for scalable applications in client-server architectures, and were formalized in seminal works such as published in 2000.

Importance and Applications

Concurrency patterns play a crucial role in modern by enhancing , responsiveness, and resource utilization in multi-core systems, allowing applications to effectively leverage parallel processing capabilities for improved performance. These patterns enable developers to structure concurrent code in ways that minimize overhead and maximize throughput, particularly as hardware evolves toward greater parallelism. By providing proven templates for handling shared resources and task coordination, they reduce the incidence of bugs arising from improper concurrency management, such as race conditions and deadlocks, thereby improving overall software reliability. In practical applications, concurrency patterns are essential for web servers, where they facilitate the simultaneous handling of multiple client requests to maintain low latency and under load. In , they support by ensuring consistent access to shared data across concurrent operations, preventing anomalies in high-throughput environments. Real-time systems, such as in and control applications, rely on these patterns to achieve predictable timing and coordination among parallel components. Similarly, in and cloud services, concurrency patterns enable efficient resource sharing and fault-tolerant operations across networked nodes. The impact of concurrency patterns on is profound, as they empower the creation of high-performance applications that can achieve significant speedups on parallel hardware, guided by principles like , which quantifies the potential benefits of parallelization. illustrates that the maximum speedup SS for a program with a parallelizable fraction PP executed on NN processors is given by: S=1(1−P)+PNS = \frac{1}{(1 - P) + \frac{P}{N}} This formula underscores the necessity of concurrency patterns to maximize PP and minimize sequential bottlenecks, thereby realizing substantial performance gains in parallel sections. Furthermore, these patterns address key challenges in concurrent systems, such as thread starvation—where certain tasks are indefinitely delayed—and the overhead from frequent context switching, which can degrade efficiency by consuming CPU cycles on thread management rather than computation. By encapsulating best practices for and , concurrency patterns mitigate these issues, promoting more robust and efficient concurrent designs. For instance, patterns like producer-consumer are applied in queue-based systems to balance workload distribution and prevent bottlenecks.

Fundamental Concepts

Concurrency versus Parallelism

Concurrency refers to the ability of a system to manage multiple tasks or computations that can progress independently or in an interleaved manner, without requiring simultaneous execution. This involves structuring programs as compositions of independently executing processes, allowing for the handling of multiple activities "at once" through techniques like or asynchronous operations. In contrast, parallelism involves the simultaneous execution of multiple computations, typically leveraging multiple processing units such as CPU cores to perform tasks concurrently in real time. A classic example of concurrency without parallelism occurs on a , where the operating system schedules multiple threads by rapidly switching between them, enabling multitasking such as a responding to several client requests sequentially but appearing simultaneous to users. Parallelism, however, demands hardware support like multi-core CPUs; for instance, a vector can be divided across multiple cores to execute parts of the calculation simultaneously, accelerating the overall result. These distinctions highlight that concurrency focuses on program design for coordination, while parallelism emphasizes execution efficiency through resource utilization. The phrase "Concurrency is not parallelism" encapsulates this separation, originating from a 2012 talk by , emphasizing that concurrency addresses the structural challenges of dealing with multiple tasks, whereas parallelism is merely one possible outcome of executing those tasks on capable hardware. This implies that concurrency patterns remain crucial for task coordination even in non-parallel environments, such as single-threaded applications with , to prevent issues like race conditions or inefficient resource use. In terms of measurement, concurrency often prioritizes throughput, defined as the number of tasks completed per unit time, by enabling the system to handle a higher volume of work through interleaving or multiplexing. Parallelism, on the other hand, typically aims to reduce latency, the time required to complete an individual task, by distributing workload across processors to shorten execution duration for compute-intensive operations.

Synchronization Primitives

Synchronization primitives are the foundational mechanisms in concurrent programming that enable threads or processes to coordinate access to shared resources, preventing issues such as race conditions and ensuring data consistency. These primitives provide low-level synchronization capabilities, often implemented through hardware instructions or operating system support, and serve as building blocks for higher-level concurrency patterns. By managing contention and signaling, they facilitate safe parallel execution in multi-threaded environments. A mutex, or lock, is a primitive that guarantees only one thread can access a of code or a at a time, thereby enforcing exclusive access to prevent concurrent modifications. Mutexes are typically implemented using atomic operations, such as instructions, or through operating system kernel calls that block contending threads. For instance, in threads (), a mutex is acquired via the pthread_mutex_lock function, which spins or blocks until the lock is available. Semaphores extend the concept of by providing a mechanism to control access to a pool of resources, allowing multiple threads to proceed up to a specified limit. Invented by in 1965, a is an integer variable that supports two atomic operations: P (wait or decrement) and V (signal or increment), ensuring that the value never goes negative. A binary semaphore, initialized to 1, behaves like a mutex for exclusive access, while a semaphore, initialized to a value greater than 1, signals availability for producer-consumer scenarios by tracking resource counts. Condition variables complement mutexes by allowing threads to wait efficiently for specific conditions to become true, rather than busy-waiting, thus reducing CPU overhead in concurrent systems. Introduced in C. A. R. Hoare's work on monitors, a condition variable supports three key operations: wait(), which releases the associated mutex and blocks the thread until signaled; signal(), which wakes one waiting thread; and broadcast(), which wakes all waiting threads. These operations are always used in conjunction with a mutex to protect the condition check and ensure thread safety, as exemplified in pthreads via pthread_cond_wait. Atomic operations provide hardware-supported primitives for lock-free , enabling threads to perform read-modify-write sequences without interruption. A prominent example is the (CAS) operation, which atomically checks if a memory location holds an and, if so, replaces it with a new value; otherwise, it fails without modification. Formally, CAS can be expressed as: CAS(address,expected,new)={trueif ∗address==expected and ∗address=newfalseotherwise\text{CAS}(address, expected, new) = \begin{cases} true & \text{if } *address == expected \text{ and } *address = new \\ false & \text{otherwise} \end{cases} This primitive, supported in hardware on architectures like x86 via the CMPXCHG instruction, forms the basis for non-blocking algorithms by allowing optimistic updates with retry loops. While locking primitives like mutexes and semaphores offer simplicity and correctness guarantees, they introduce overhead from context switches and potential contention under high load, leading to limits in multi-core systems. In contrast, non-blocking alternatives using atomic operations like CAS avoid blocking but may incur retry costs due to contention, resulting in trade-offs where lock-free approaches excel in low-contention or high-parallelism scenarios but can underperform in others due to increased complexity and ABA problems. Empirical studies show that lock-free queues can achieve higher throughput than locking versions under heavy contention on multi-processor systems, often comparable to or better than sophisticated lock-based designs.

Synchronization Patterns

Producer-Consumer Pattern

The producer-consumer pattern is a fundamental synchronization mechanism in concurrent programming that decouples the production of data from its consumption, allowing producers and consumers to operate at different speeds without direct coordination. In this pattern, one or more producer threads generate data items and place them into a shared buffer, while one or more consumer threads retrieve and process those items from the buffer. The buffer serves as an intermediary that smooths out discrepancies in production and consumption rates, preventing producers from overwhelming the system or consumers from idling unnecessarily. This approach originated in early work on synchronization, where it was used to illustrate the need for coordination in shared-resource environments. The core structure of the pattern revolves around a bounded buffer, typically implemented as a fixed-size circular queue to avoid unbounded memory growth and potential overflows. Producers append items to the buffer only when space is available, and consumers remove items only when the buffer is not empty. To manage access and availability, the pattern employs primitives such as a mutex for on the buffer and to track the number of empty and full slots. The empty is initialized to the buffer's capacity, the full to zero, and the mutex to one, ensuring atomic operations during insertion and removal. This setup handles speed differences by blocking producers when the buffer is full and consumers when it is empty, thereby maintaining system stability. The components interact through a well-defined protocol. For the producer, the sequence involves waiting on the empty semaphore to ensure space, acquiring the mutex to access the buffer, adding the item, releasing the mutex, and signaling the full semaphore to notify consumers. The consumer follows a symmetric process: waiting on the full semaphore for an available item, acquiring the mutex, removing the item, releasing the mutex, and signaling the empty semaphore. This orchestration prevents race conditions and ensures that buffer indices (e.g., input and output pointers in a circular array) are updated safely. Here is the standard pseudocode for the bounded buffer implementation using semaphores: Producer:

do { wait(empty); wait(mutex); /* add item to buffer */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; signal(mutex); signal(full); } while (true);

do { wait(empty); wait(mutex); /* add item to buffer */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; signal(mutex); signal(full); } while (true);

Consumer:

do { wait(full); wait(mutex); /* remove item from buffer */ next_consumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; signal(mutex); signal(empty); /* consume the item */ } while (true);

do { wait(full); wait(mutex); /* remove item from buffer */ next_consumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; signal(mutex); signal(empty); /* consume the item */ } while (true);

where empty is initialized to BUFFER_SIZE, full to 0, mutex to 1, and BUFFER_SIZE is the fixed buffer capacity. Variations of the pattern include unbounded queues, which use a dynamically growing instead of a fixed , eliminating the full and the risk of overflow but requiring careful to avoid exhaustion. This simplifies for cases where production rates are unpredictable but increases complexity in multi-producer scenarios due to potential contention on the tail pointer. Another variation appears in message-passing systems, where the buffer is replaced by channels that facilitate direct communication between producers and consumers without , as in (CSP), enabling distributed coordination. The pattern offers key benefits, including the prevention of busy-waiting through blocking semaphores, which allow threads to suspend execution until conditions are met, conserving CPU resources compared to polling loops. Additionally, by buffering data and enabling concurrent operation, it improves overall throughput in systems where producers and consumers have mismatched processing speeds, allowing the pipeline to sustain higher data flow rates without bottlenecks.

Reader-Writer Pattern

The reader-writer pattern addresses the challenge of concurrent access to shared resources where multiple readers can access the data simultaneously without interference, but writers require exclusive access to prevent , while also mitigating the risk of writer in scenarios dominated by read operations. This pattern optimizes throughput by allowing concurrent reads, which is particularly beneficial when reads vastly outnumber writes, as a simple lock would serialize all access and underutilize the resource. Two primary variants exist: reader-preference, which prioritizes readers by allowing new readers to join immediately if no writer is active, potentially leading to delayed writers but minimizing reader wait times; and writer-preference, which gives priority to waiting s by blocking new readers once a writer is queued, ensuring writers proceed sooner but risking reader . However, the reader-preference variant can lead to writer starvation if new readers continue to arrive while a writer is waiting, as new readers can acquire the lock before the waiting writer, whereas writer-preference may indefinitely postpone readers if writers arrive continuously. Both variants rely on primitives like semaphores or locks to enforce these policies. Implementation typically involves a shared lock for readers, an exclusive lock for writers, a counter to track active readers, and condition variables or to manage waiting threads. In the reader-preference approach using , a mutex semaphore protects the reader count, and a wrt (write) semaphore ensures writer exclusion; readers increment a readcount and acquire wrt only if they are the first, while writers solely acquire wrt. The writer-preference variant adds additional to block incoming readers when writers are pending. Here is pseudocode for the reader-preference variant: Reader Process:

P(mutex) readcount++ if (readcount == 1) P(wrt) V(mutex) -- perform read operation -- P(mutex) readcount-- if (readcount == 0) V(wrt) V(mutex)

P(mutex) readcount++ if (readcount == 1) P(wrt) V(mutex) -- perform read operation -- P(mutex) readcount-- if (readcount == 0) V(wrt) V(mutex)

Writer Process:

P(wrt) -- perform write operation -- V(wrt)

P(wrt) -- perform write operation -- V(wrt)

This ensures multiple readers can proceed concurrently but blocks writers until no readers are active, with the mutex preventing race conditions on readcount. The pattern finds applications in , where query operations (reads) far outnumber updates (writes), allowing multiple transactions to read simultaneously while serializing modifications; similarly, in file systems, it supports concurrent reads of file contents alongside exclusive writes to maintain .

Architectural Patterns

Active Object Pattern

The pattern is a behavioral concurrency that decouples method invocation from method execution, enabling objects to operate in their own thread of control while providing a synchronous interface to clients. This separation allows for asynchronous processing of requests, simplifying the management of concurrent access to shared resources without requiring clients to handle threading explicitly. By encapsulating concurrency within the object, the pattern promotes modular design in multi-threaded applications, such as those involving networked or real-time systems. The structure involves clients sending requests to a Proxy, which serializes them into a queue for deferred execution by a Servant running in a dedicated thread. A Scheduler manages the Activation Queue (also known as the activation list), dispatching Method Requests in a controlled order, often using a Producer-Consumer mechanism to ensure thread-safe queuing. The Activation List tracks pending operations and manages Futures for clients awaiting results asynchronously, thus hiding the execution thread from the invocation context. This component-based architecture enforces single-threaded semantics within the servant, eliminating the need for fine-grained locks on individual methods. Key benefits include simplified , as all method executions occur sequentially in one thread, reducing race conditions and easing testing and of object behavior in isolation. It also enhances overall system concurrency by allowing multiple client threads to invoke methods without blocking, while leveraging parallelism for independent objects. Clients benefit from a familiar, blocking interface that internally translates to non-blocking operations, improving . A representative example is in graphical user interfaces (GUIs), such as chat applications, where the decouples network I/O from the UI thread to prevent latency from freezing the interface, often by queuing events for processing on the main event-dispatch thread. Another application appears in communication gateways, where an processes incoming data packets from multiple sources, handling flow control without degrading service quality for any single client. Despite these advantages, the pattern introduces overhead from message queuing and dispatching, which can add latency and reduce throughput in latency-sensitive or high-volume scenarios. is complicated by the asynchronous flow, as execution order depends on the scheduler and queue state, potentially obscuring cause-and-effect relationships in traces.

Thread Pool Pattern

The pattern is a concurrency that maintains a collection of pre-allocated worker threads to execute submitted tasks, reducing the overhead of frequent thread creation and termination in applications requiring high concurrency. By reusing a fixed or bounded set of threads, the pattern improves resource efficiency and predictability, particularly in environments where tasks arrive unpredictably, such as server applications handling multiple client requests. This approach decouples task submission from execution, allowing producers to submit work without blocking while workers consume and process it from a shared queue, often leveraging primitives like blocking queues to manage access. The core structure of the Thread Pool pattern involves pre-allocating a pool of worker threads that remain idle until tasks are available, with tasks enqueued for execution rather than spawning new threads per task. Key components include the pool manager, which oversees thread lifecycle, sizing, and shutdown operations; the task queue, a thread-safe buffer (typically a blocking queue) that holds pending tasks and notifies workers when items are available; and the worker threads themselves, which continuously poll or wait on the queue to fetch and execute tasks. The manager ensures that idle threads are reused, and if the queue fills, it may reject tasks or expand the pool temporarily depending on the configuration. Determining the optimal pool size balances CPU utilization and task latency, typically based on the number of available CPU cores and the nature of the workload—CPU-bound tasks favor sizes close to core count, while I/O-bound tasks benefit from larger pools to overlap waiting periods. A common heuristic for sizing is the formula Nthreads=NCPU×(1+WC)N_{threads} = N_{CPU} \times \left(1 + \frac{W}{C}\right), where NCPUN_{CPU} is the number of CPU cores, WW is the average wait time per task (e.g., for I/O), and CC is the average compute time per task; this accounts for time spent waiting versus processing to maximize throughput without excessive context switching. For instance, in CPU-bound scenarios with minimal waiting, the pool size approximates the core count to avoid oversubscription. The pattern finds widespread application in web servers, such as , where a processes incoming HTTP requests by assigning them to available workers, enabling scalable handling of concurrent connections without exhausting system resources. It is also commonly used in systems to parallelize independent jobs, like data transformations or simulations, distributing them across the pool for faster completion. Variations of the Thread Pool pattern include dynamic pools that automatically grow or shrink based on demand, such as cached thread pools that create new threads when needed but reclaim idle ones after a timeout to adapt to varying loads. Fixed-size pools maintain a constant number of threads for predictable resource usage, while scheduled variants allow timed or periodic task execution, extending the basic structure for recurring workloads.

Advanced Considerations

Deadlock Detection and Prevention

Deadlock occurs in concurrent systems when two or more es or threads are unable to proceed because each is waiting for resources held by the others, forming a . This situation arises particularly in systems employing primitives like mutexes, where improper locking order can lead to indefinite blocking. For deadlock to manifest, four necessary conditions, known as the Coffman conditions, must all hold simultaneously: (resources cannot be shared and must be held exclusively), hold-and-wait (a process holding at least one resource waits for another), no preemption (resources cannot be forcibly taken from a process), and circular wait (a cycle exists in the resource ). These conditions, first formalized by Edward G. Coffman Jr. in 1971, provide a foundational framework for analyzing and mitigating deadlocks in resource-contested environments. Deadlock detection involves identifying these conditions at runtime or preemptively. One common method uses resource allocation graphs, where nodes represent processes and resources, and directed edges indicate allocation and requests; a cycle in the graph for single-instance resources signals a deadlock. The Banker's algorithm, developed by in 1965, addresses avoidance by simulating resource requests to ensure the system remains in a safe state—a sequence of process executions that avoids deadlock—before granting allocations. In practice, runtime detection often relies on tools like thread dumps, which capture stack traces to reveal waiting threads, or utilities such as jstack for applications, which explicitly checks for and reports deadlock cycles. Prevention strategies aim to violate at least one Coffman condition proactively. Imposing a total order on resources—requiring locks to be acquired in a consistent sequence—breaks circular wait by eliminating cycles in the . Timeouts on lock acquisitions can prevent hold-and-wait by forcing release after a period, allowing other processes to proceed, though this may introduce livelock risks if not managed carefully. Deadlock-free primitives, such as hierarchical locking where locks are nested in a predefined order, further ensure no circular dependencies form. Upon detection, recovery typically involves terminating one or more processes to , often selecting the victim based on priority or to minimize disruption. In database systems, is a preferred mechanism, where the aborted transaction is reverted to its initial state, preserving atomicity and consistency as per properties; for instance, partial techniques allow only the conflicting operations to be undone without restarting the entire transaction. These techniques are essential for the safe application of concurrency patterns, such as the Reader-Writer pattern where multiple readers share access but writers require exclusive locks, or patterns managing shared resources among worker threads, ensuring that synchronization does not lead to system-wide stalls.

Performance Optimization Techniques

Lock-free programming represents a key optimization technique in concurrent systems, leveraging atomic operations such as (CAS) to enable non-blocking progress among threads without traditional locks. This approach ensures that at least one thread makes progress in every step of execution, avoiding the overhead of lock acquisition and release that can lead to contention in high-throughput scenarios. Seminal work by Michael and Scott introduced a practical lock-free FIFO queue algorithm using CAS operations on pointers to update the queue's head and tail atomically, demonstrating how such primitives can support scalable data structures like queues in multiprocessor environments. A common challenge in lock-free designs is the , where a thread reads a value (A), another thread modifies it and then restores it to A, leading the first thread to incorrectly assume no change occurred during a CAS operation. This issue arises in pointer-based structures and can cause incorrect behavior or infinite loops. To mitigate the , hazard pointers provide a safe memory reclamation mechanism; threads announce their interest in specific nodes via hazard pointers, deferring deallocation until no hazards reference them, thus ensuring visibility and correctness in lock-free objects like lists or queues. Profiling tools are essential for identifying bottlenecks in concurrent applications, measuring metrics such as lock contention rates—which indicate the frequency of threads blocking on shared resources—and cache misses, which reveal inefficiencies in data locality across cores. In environments, the Java Flight Recorder (JFR) collects low-overhead diagnostic data, including thread contention timelines and events, enabling developers to pinpoint hotspots in lock-based patterns. On systems, the perf tool samples hardware events like cache misses and context switches, providing insights into concurrency overheads such as inter-core communication delays. Several optimizations enhance the efficiency of concurrency patterns by minimizing costs. Reducing lock —shifting from coarse-grained locks that protect large sections to fine-grained locks on smaller components—lowers contention in read-heavy workloads, as multiple threads can access disjoint parts simultaneously, though it increases the risk of deadlocks if not managed carefully. Immutable further optimizes performance by allowing threads to read shared structures without , since immutability guarantees no in-place modifications; reference immutability techniques, for instance, enable safe parallel access to persistent data structures by restricting to unique references. In thread pools, work-stealing queues improve load balancing by allowing idle threads to "steal" tasks from busy peers' double-ended queues, reducing idle time and enhancing in dynamic workloads like parallel computations. Benchmarks in concurrency often evaluate by measuring throughput as the number of cores increases, revealing how patterns handle contention; lock-free structures typically exhibit linear up to dozens of cores, outperforming locked variants under high contention due to reduced blocking. , a fundamental queuing theorem, applies to concurrent queue systems by relating average queue length LL to arrival rate λ\lambda and average wait time WW via the equation L=λWL = \lambda W, helping predict system capacity and identify bottlenecks like excessive queuing in producer-consumer patterns. For example, in a queue, monitoring LL can guide optimizations to maintain low WW as λ\lambda scales with cores. These techniques involve trade-offs, particularly in high-contention scenarios where lock-free methods yield significant gains—up to 10x throughput improvements in benchmarks—but introduce implementation complexity due to subtle race conditions and the need for barriers, making them suitable only when profiling confirms locking overhead dominates. Thread pool sizing can benefit from such optimizations, as work-stealing adjusts dynamically to core count without fixed limits.

References

  1. https://www.dre.vanderbilt.edu/~schmidt/POSA/POSA2/conc-patterns.html
  2. https://dl.acm.org/doi/pdf/10.1145/269629.269648
  3. https://www.cs.wm.edu/~dcschmidt/PDF/ICSE-03.pdf
  4. https://go.dev/talks/2012/concurrency.slide
  5. https://queue.acm.org/detail.cfm?id=1095421
  6. https://dl.acm.org/doi/10.1145/1808954.1808964
  7. https://ieeexplore.ieee.org/document/7353865
  8. https://dl.acm.org/doi/10.1145/3723178.3723261
  9. https://queue.acm.org/detail.cfm?id=2940294
  10. https://www3.cs.stonybrook.edu/~rezaul/Spring-2019/CSE613/reading/Amdahl-1967.pdf
  11. https://go.dev/talks/2012/waza.slide
  12. https://homes.cs.washington.edu/~djg/teachingMaterials/spac/sophomoricParallelismAndConcurrency.pdf
  13. https://www.cs.fsu.edu/~baker/opsys/notes/mutex.html
  14. https://pure.tue.nl/ws/files/4279816/344354178746665.pdf
  15. https://www.cs.utexas.edu/~EWD/transcriptions/EWD01xx/EWD123.html
  16. https://research.cs.queensu.ca/home/cordy/cisc860/Biblio/hurd/misc/hoare74.pdf
  17. https://www.sysnet.ucsd.edu/~voelker/class/cse120/condvars.html
  18. https://www.cs.rochester.edu/u/scott/papers/1996_PODC_queues.pdf
  19. https://timharris.uk/papers/2007-tocs.pdf
  20. https://pages.cs.wisc.edu/~remzi/OSTEP/threads-sema.pdf
  21. https://cseweb.ucsd.edu/classes/sp05/cse128/chapter3.pdf
  22. https://www.cs.sfu.ca/~ashriram/Courses/CS431/assets/distrib/AMP.pdf
  23. https://w3.cs.jmu.edu/kirkpams/OpenCSF/Books/csf/html/ProdCons.html
  24. https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf
  25. https://dl.acm.org/doi/10.1145/362759.362813
  26. https://www.cs.unc.edu/~anderson/papers/ecrts09b-long.pdf
  27. https://arxiv.org/pdf/1810.01553
  28. https://www.dre.vanderbilt.edu/~schmidt/PDF/Act-Obj.pdf
  29. https://www.cse.chalmers.se/research/hats/sites/default/files/HATS_CD_Period2/Publications2010/Conferences/JCoBox_GeneralizingActiveObjectsToConcurrentComponents.pdf
  30. https://jcip.net/
  31. https://www.baeldung.com/thread-pool-java-and-guava
  32. https://dl.acm.org/doi/10.1145/582318.582329
  33. https://www.cs.otago.ac.nz/cosc440/readings/hazard-pointers.pdf
  34. https://docs.oracle.com/en/java/javase/21/troubleshoot/diagnostic-tools.html
  35. https://www.brendangregg.com/perf.html
  36. https://oasis.library.unlv.edu/cgi/viewcontent.cgi?article=4733&context=thesesdissertations
  37. https://www.cs.drexel.edu/~csg63/papers/oopsla12.pdf
  38. https://www.lri.fr/~cecile/ENSEIGNEMENT/IPAR/Exposes/cilk1.pdf
  39. https://queue.acm.org/detail.cfm?id=2492433
  40. https://arxiv.org/pdf/1609.08372
Add your contribution
Related Hubs
User Avatar
No comments yet.