Tema: concurrency
-
Cancellation and deadlines in Go with context.Context
Thread a context.Context from the incoming request through every call that can block, derive child contexts with WithTimeout or WithCancel, always call the cancel function, and check ctx.Done() in loops so that a client disconnect or a deadline stops the whole tree of goroutines instead of leaving them running.
-
When asyncio helps and when it does not
asyncio runs many I/O-bound tasks on one thread by suspending at await points; it does not speed up CPU-bound code, and blocking calls inside coroutines stall the whole loop.
-
Transaction isolation levels in practice
Read committed, repeatable read and serializable trade concurrency for consistency; knowing which anomalies each level allows decides when to add explicit locks or retries.
-
Choosing between threads, processes and asyncio for a Python workload
Classify the hot path first: waiting on I/O suits asyncio (many connections, async libraries) or a thread pool (few blocking calls); pure-Python CPU work needs processes or a free-threaded build; native code that releases the GIL can use threads. Bound every pool, choose the process start method explicitly and write the shutdown path.
-
Verify read-after-write using returned revisions
Confirm a write through its stable identifier and revision without mistaking a newer concurrent update for the exact content you submitted.
-
Handle stale write tokens as reread signals
Recover from a failed write precondition by rereading and rebuilding the intended change against the current version.
-
At what workload does the free-threaded CPython build beat a process pool for a mixed I/O and CPU service?
Open question: the free-threaded build removes the GIL but adds single-threaded overhead and may fall back to the GIL when an unprepared extension is imported, while process pools pay for pickling and memory duplication; for which CPU-to-wait ratios, working sets and core counts does a thread pool on the free-threaded build deliver more throughput per core?
-
C# async/await pitfalls: sync-over-async, async void and ConfigureAwait
The classic mistakes in C# asynchronous code are blocking on a Task with .Result, .Wait() or GetAwaiter().GetResult() (deadlocks under a single-threaded SynchronizationContext, thread-pool starvation on servers), async void methods whose exceptions cannot be caught, and misplacing ConfigureAwait(false), which belongs in general-purpose libraries and not in application code.
-
Java virtual threads in outline: what changes and what does not
JEP 444 (JDK 21) adds virtual threads: cheap threads scheduled by the JDK onto a small pool of carrier platform threads, which unmount while blocked on most JDK I/O so that thread-per-request code scales without an asynchronous style. They are not faster, must never be pooled, and until JEP 491 (JDK 24) blocking inside synchronized pinned the carrier.
-
Use expiring leases for distributed jobs
Protect a reclaimed job from a delayed previous worker with ownership checks and a monotonically increasing fencing token.
-
The GIL: what it serialises and what it does not make safe
The global interpreter lock lets only one thread execute Python bytecode at a time and protects the interpreter's own structures, not the program's invariants: read-modify-write sequences such as counter += 1 or check-then-set on a dict still need a threading.Lock. Free-threaded builds keep the same rule.
-
Goroutines, channels and the sync package: Go concurrency in outline
A go statement runs a function call concurrently on a cheap, growable stack; channels move values between goroutines and block until both sides are ready; sync.WaitGroup, Mutex and Once cover the cases where sharing memory is simpler. A data race is a bug whose outcome the memory model only partly constrains, and the -race detector is the tool for finding it.
-
Bound concurrency per host and account
Control simultaneous tool calls separately from request rate, with bounded queues and cancellation-safe permit release.
Legible por máquina: JSON