Race Conditions
Race conditions occur when multiple threads access shared resources concurrently, and the final outcome depends on the relative timing of their execution. This can lead to unexpected and incorrect behavior of the program.
Consider the following example in Java:
public class Counter {
private int count = 0;
public void increment() {
count++;
}
public int getCount() {
return count;
}
}
If multiple threads invoke the increment()
method simultaneously, a race condition can occur, leading to lost updates or inconsistent state.
To mitigate race conditions, proper synchronization mechanisms should be used to ensure exclusive access to shared resources. In Java, the synchronized
keyword can be used to create a lock on the critical section:
public synchronized void increment() {
count++;
}
In Golang, the sync
package provides the Mutex
type for locking:
type Counter struct {
mu sync.Mutex
count int
}
func (c *Counter) Increment() {
c.mu.Lock()
defer c.mu.Unlock()
c.count++
}
Deadlocks
Deadlocks occur when two or more threads are waiting for each other to release resources that they hold, resulting in a circular dependency. This leads to a situation where the threads are stuck and unable to proceed.
Consider the following example in Java:
public void transferMoney(Account from, Account to, int amount) {
synchronized (from) {
synchronized (to) {
from.withdraw(amount);
to.deposit(amount);
}
}
}
If multiple threads invoke the transferMoney()
method with different account combinations, a deadlock can occur if the locks are acquired in a different order.
To prevent deadlocks, a consistent ordering of lock acquisition should be followed. In the above example, acquiring the locks in a fixed order (e.g., based on account ID) can help avoid deadlocks:
public void transferMoney(Account from, Account to, int amount) {
Account firstLock = from.getId() < to.getId() ? from : to;
Account secondLock = from.getId() < to.getId() ? to : from;
synchronized (firstLock) {
synchronized (secondLock) {
from.withdraw(amount);
to.deposit(amount);
}
}
}
In Golang, the sync
package provides the Mutex
type for locking, and deadlocks can be avoided by acquiring locks in a consistent order:
func transferMoney(from, to *Account, amount int) {
if from.ID < to.ID {
from.mu.Lock()
defer from.mu.Unlock()
to.mu.Lock()
defer to.mu.Unlock()
} else {
to.mu.Lock()
defer to.mu.Unlock()
from.mu.Lock()
defer from.mu.Unlock()
}
from.Withdraw(amount)
to.Deposit(amount)
}
Resource Starvation
Resource starvation occurs when a thread is unable to acquire the necessary resources to make progress, leading to a situation where it is perpetually blocked or unable to proceed.
Consider a scenario where multiple threads are competing for a limited number of database connections. If the connections are not properly managed or released, some threads may be starved and unable to acquire a connection.
To mitigate resource starvation, efficient resource management techniques should be employed. This includes properly releasing resources when they are no longer needed, using connection pools to manage and reuse database connections, and implementing fair scheduling algorithms to ensure equitable distribution of resources among threads.
In Java, the ThreadPoolExecutor
class provides a thread pool implementation that manages a pool of worker threads and allows for efficient resource utilization:
ThreadPoolExecutor executor = new ThreadPoolExecutor(
corePoolSize, maxPoolSize, keepAliveTime, TimeUnit.SECONDS,
new LinkedBlockingQueue<>()
);
// Submit tasks to the thread pool
executor.submit(task1);
executor.submit(task2);
In Golang, the goroutine
and channel
primitives can be used to manage resources and prevent starvation:
func worker(tasks <-chan Task, results chan<- Result) {
for task := range tasks {
result := performTask(task)
results <- result
}
}
func main() {
tasks := make(chan Task, 100)
results := make(chan Result, 100)
// Create a pool of worker goroutines
for i := 0; i < numWorkers; i++ {
go worker(tasks, results)
}
// Submit tasks to the worker pool
for _, task := range taskList {
tasks <- task
}
close(tasks)
// Collect results from the worker pool
for i := 0; i < len(taskList); i++ {
result := <-results
fmt.Println(result)
}
}