What is Synchronization
-
Coordination b/w processes/threads to access shared resources so that
deadlock & race conditions
can be avoided.
Ex-1: When multiple threads need to modify a shared resource (e.g. global variable) we should lock the resource to guarantee at most 1 thread can do modification.
Ex-2: When 2 threads are putting data on top of stack, without synchronization it is impossible to tell what is on top of the stack at any one time.
Different Synchronization Methods
Methods are grouped by language. The Sync column marks thread synchronization; IPC marks inter-process communication.
| Language | Method / API | Description | Sync | IPC |
|---|---|---|---|---|
| C++ |
std::mutex
|
Exclusive lock for shared data. Use with
lock_guard or unique_lock.
|
Yes | No |
std::shared_mutex (RwLock) |
Many readers or one writer at a time. | Yes | No | |
std::condition_variable
|
Lets threads wait until another thread signals a condition (used with a mutex). | Yes | No | |
std::atomic |
Lock-free atomic read/modify on integers and pointers. | Yes | No | |
std::counting_semaphore / barrier (C++20) |
Limit concurrent access; synchronize at a barrier point. | Yes | No | |
| Rust |
Arc<T>
|
Atomically reference-counted shared ownership. Read-only unless wrapped with interior mutability. | Yes | No |
Mutex<T>
|
Exclusive lock around data. Plain mutex is not shareable across threads by itself. | Yes | No | |
Arc<Mutex<T>>
|
Share a mutex-protected value across multiple threads. | Yes | No | |
RwLock<T> |
Multiple readers or one writer (often inside Arc).
|
Yes | No | |
Channels (mpsc)
|
Message passing between threads; send/receive blocks until both sides are ready. | Yes | Yes | |
std::sync::atomic |
Low-level atomic types (AtomicBool, etc.). |
Yes | No | |
| Java |
synchronized keyword
|
Intrinsic lock on a method or block. Every object has an associated monitor lock. | Yes | No |
ReentrantLock
|
Explicit lock from java.util.concurrent.locks; same
thread can re-enter.
|
Yes | No | |
ReadWriteLock
|
Separate read and write locks for shared data structures. | Yes | No | |
volatile
|
Visibility guarantee (no caching in thread-local CPU cache). Does not make compound operations atomic. | Partial | No | |
java.util.concurrent
(Semaphore, CountDownLatch, CyclicBarrier, Phaser)
|
Higher-level coordination between threads. | Yes | No | |
BlockingQueue,
ConcurrentHashMap
|
Thread-safe collections with built-in synchronization. | Yes | No | |
| Go | sync.Mutex |
Exclusive lock; idiomatic for protecting shared memory. | Yes | No |
sync.RWMutex |
Many readers or one writer. | Yes | No | |
| Channels | Primary Go idiom — goroutines communicate by sending on channels (buffered / unbuffered, directional). | Yes | Yes | |
sync/atomic
|
Lock-free atomic operations on integers and pointers. | Yes | No | |
sync.WaitGroup |
Wait for a group of goroutines to finish. | Yes | No | |
select |
Wait on multiple channel operations at once. | Yes | No | |
| Python | threading.Lock |
Basic mutex for threads within one process. | Yes | No |
threading.RLock |
Reentrant lock — same thread can acquire it multiple times. | Yes | No | |
threading.Semaphore / Event |
Limit concurrent access; signal between threads. | Yes | No | |
threading.Condition |
Wait for a condition while holding a lock. | Yes | No | |
queue.Queue |
Thread-safe FIFO queue (producer–consumer between threads). | Yes | Yes | |
multiprocessing.Lock / Pipe |
Synchronization and messaging between processes (bypasses GIL). | Yes | Yes | |
| POSIX / OS |
pthread_mutex
|
C/POSIX mutex used by native code and some runtimes. | Yes | No |
| Pipes | Byte stream between processes (anonymous or named FIFO). | No | Yes | |
| Shared Memory | Multiple processes map the same physical memory region. | Yes | Yes | |
| Semaphores / Barriers (POSIX) | OS-level counting semaphores and barrier synchronization. | Yes | Yes |