Skip to main content
Back to Tags

Concurrency

45 items tagged with "concurrency"

Filter by type:

Patterns14

Pattern

Singleton

Ensures a class has only one instance and provides a global point of access to it, used for shared resources like configuration, logging, or connection pools.

Pattern

Object Pool

Reuses a set of pre-initialized, expensive-to-create objects from a managed pool instead of creating and destroying them on demand, improving performance.

Pattern

Lazy Initialization

Defers the creation or computation of an object until the first time it is actually needed, avoiding upfront cost for resources that may never be used.

Pattern

Multiton

Generalizes Singleton to manage a fixed, keyed set of named instances, ensuring exactly one instance exists per key through a registry.

Pattern

Leader Election

Designates a single instance among many to coordinate work, with automatic failover if the leader becomes unavailable.

Pattern

Distributed Lock

Coordinates exclusive access to a shared resource across multiple processes or nodes that do not share memory.

Pattern

Sequential Convoy

Process related messages in order while still processing unrelated messages in parallel, by grouping them into ordered sets.

Pattern

Producer-Consumer

A concurrency pattern where producers place work on a shared bounded queue and consumers process it independently, decoupling rates and smoothing load.

Pattern

Thread Pool

A concurrency pattern that reuses a fixed set of worker threads to execute many tasks, avoiding per-task thread creation cost and bounding concurrency.

Pattern

Actor Model

A concurrency model where independent actors encapsulate state and communicate only by asynchronous messages, avoiding shared memory and locks.

Pattern

Reactor

An event-handling pattern that demultiplexes I/O events on one or few threads and dispatches them synchronously to registered handlers, enabling scalable non-blocking servers.

Pattern

Optimistic Concurrency Control

A concurrency strategy that lets transactions proceed without locking and validates at commit, retrying on conflict, assuming conflicts are rare.

Pattern

Pessimistic Locking

A concurrency strategy that acquires locks on data before use to prevent concurrent modification, ensuring correctness under high contention at the cost of throughput.

Pattern

Two-Phase Commit (2PC)

A distributed-transaction protocol that coordinates multiple participants to commit or abort atomically through a prepare phase and a commit phase.

Anti-Patterns8

Anti-Pattern

Busy-Waiting (Spin-Waiting)

Repeatedly polling a condition in a tight loop instead of blocking, burning CPU cycles while waiting for an event that the scheduler could deliver for free.

Anti-Pattern

Lock Contention

Many threads competing for the same lock, serializing work that should run in parallel and turning a multicore machine into an expensive single-core one.

Anti-Pattern

Deadlock-Prone Locking

Acquiring multiple locks in inconsistent orders so two threads can each hold one lock while waiting for the other, freezing both forever.

Anti-Pattern

Broken Double-Checked Locking

A lazy-initialization idiom that checks a field outside a lock, locks, then checks again — but without proper memory barriers it returns partially constructed objects.

Anti-Pattern

Thread-Per-Request Overload

Spawning a dedicated OS thread for every incoming request, so concurrency is capped by thread count and memory, collapsing under load instead of degrading gracefully.

Anti-Pattern

Blocking the Event Loop

Running CPU-heavy or synchronous work on a single-threaded event loop, stalling every other in-flight request until it finishes.

Anti-Pattern

Synchronous-Over-Async (sync-over-async)

Blocking a thread to wait on an asynchronous operation's result, combining the costs of both models and risking thread-pool starvation or deadlock.

Anti-Pattern

False Sharing

Independent variables that happen to live on the same CPU cache line, so updates by different cores invalidate each other's caches and silently destroy multicore performance.

Comparisons9

Comparison

Go vs Rust

Two modern systems-oriented languages: Go optimizes for simplicity and fast development, Rust for memory safety without a garbage collector and maximum control.

Comparison

Rust vs C++

Both target systems-level performance, but Rust enforces memory safety at compile time while C++ offers unmatched maturity and ecosystem at the cost of manual safety.

Comparison

Python vs Go

Python prioritizes expressiveness and a vast data/AI ecosystem, while Go prioritizes raw performance, concurrency, and lean deployment for services.

Comparison

Node.js vs Python

Two leading backend runtimes: Node.js offers event-driven, non-blocking I/O with JavaScript everywhere, while Python brings readability and a vast data ecosystem.

Comparison

Go vs Node.js for APIs

For building HTTP and gRPC APIs, Go offers compiled performance and easy concurrency, while Node.js offers rapid development and full-stack JavaScript.

Comparison

Async/Await vs Threads

Two models for concurrency: cooperative asynchronous programming with an event loop, versus preemptive OS threads. Each suits different workloads.

Comparison

C vs Rust for Systems Programming

C is the foundational systems language behind operating systems and embedded software, while Rust offers comparable control with compiler-enforced memory safety.

Comparison

Java Virtual Threads vs Reactive Programming

Two approaches to scalable concurrency on the JVM: Project Loom's virtual threads keep simple blocking code, while reactive programming uses non-blocking streams.

Comparison

Kotlin vs Java for Android

Kotlin is Google's preferred, modern language for Android; Java is the original, ubiquitous JVM language with the largest legacy footprint.