Concurrent Programming

How concurrent programming works

Concurrent programming lets a system make progress on more than one task during the same time window. The tasks may be interleaved on one core or executed in parallel across multiple cores, but the design problem is the same: keep work coordinated without corrupting shared state.

The practical difference from sequential code is that execution order is no longer fixed. Threads, processes, async routines, and event loops all introduce scheduling variability, so a correct program must tolerate different interleavings and still produce valid results.

Shared state, ordering, and synchronisation

Concurrency becomes difficult when tasks can read and write the same memory, files, queues, or other mutable resources. The programmer has to decide what can be shared, what must be isolated, and where coordination is required to preserve correctness.

Common synchronisation mechanisms include locks, semaphores, mutexes, condition variables, message passing, and atomic operations. Each one narrows the set of possible interleavings, but each also adds overhead, complexity, and the possibility of contention or deadlock if used poorly.

Async models often reduce blocking, but they do not remove coordination problems. They shift the focus from thread safety to await points, shared callbacks, and careful management of state that may be resumed later by a different execution context.

Concurrency versus parallelism

Concurrency and parallelism are related but not identical. Concurrency is about structuring a program so multiple activities can overlap in time; parallelism is about actually running those activities at the same instant on separate execution resources.

A concurrent program may run on a single CPU and still interleave tasks efficiently. That is common in I/O-heavy systems, user interfaces, servers, and event-driven services where waiting dominates computation. Parallelism matters more when the workload is CPU-bound and can be split into independent units of work.

The architectural choice affects scaling, latency, and failure modes. Systems built for concurrency often improve responsiveness, while systems built for parallelism aim to increase throughput. Many production systems use both, but they need different reasoning about scheduling and resource use.

Common failure modes and design trade-offs

Concurrency bugs are often intermittent because they depend on timing. Race conditions, deadlocks, livelocks, starvation, and inconsistent reads can appear only under load, after a deployment, or on a different hardware profile.

These failures are especially hard to debug because the program may look correct in a single-threaded test and fail only when scheduling changes. For that reason, concurrent code usually demands stricter testing, clearer state ownership, and a deliberate approach to shared-resource boundaries.

There is also a trade-off between safety and performance. More locking can improve correctness but reduce throughput; less locking can improve speed but increase the chance of subtle corruption. Good concurrent design tries to minimise shared mutable state rather than rely on ever more complex coordination.

Risk and Threat Considerations

Concurrent programming creates real security and reliability exposure when shared state is updated without correct coordination. Small timing flaws can become data corruption, privilege confusion, request mix-ups, or denial of service when they occur inside authentication, queue processing, caching, or session-handling paths.

Failure mechanism: An attacker or fault condition can exploit a race, deadlock, or inconsistent state transition to force the program into an invalid outcome, especially when one task checks a condition and another task changes it before the action completes.

Impact: The result can be incorrect authorisation, duplicate processing, corrupted records, stuck workers, or service instability that is difficult to reproduce and therefore easy to overlook until it is abused at scale.

Practitioner Guidance

What to watch for: Treat concurrency as a correctness discipline, not just a performance technique. The safest designs are the ones that reduce shared mutable state, make ownership explicit, and keep coordination boundaries narrow enough that state transitions are easy to reason about.

Practitioner note: When a system grows from a few threads into a mixed model of threads, async work, and background jobs, the most important review is often not “is it fast enough?” but “can two execution paths ever observe or modify the same state in the wrong order?”

Related resources from NHI Mgmt Group

• What breaks when concurrent sessions are not controlled in Active Directory?
• How should security teams control concurrent sessions for privileged accounts?
• Why do concurrent logins create more risk in Active Directory environments?
• What breaks when concurrent access is not controlled in native AI runtimes?