Top 21 Concurrency Interview Questions And Answers

Q: Explain the difference between Asynchronous and Parallel programming?

When you run something **asynchronously** it means it is non\-blocking, you execute it without waiting for it to complete and carry on with other things. **Parallelism** means to run multiple things at the same time, in parallel. Parallelism works well when you can separate tasks into independent pieces of work. Async and Callbacks are generally a way (tool or mechanism) to express concurrency i.e. a set of entities possibly talking to each other and sharing resources. Take for example rendering frames of a 3D animation. To render the animation takes a long time so if you were to launch that render from within your animation editing software you would make sure it was running *asynchronously* so it didn't lock up your UI and you could continue doing other things. Now, each frame of that animation can also be considered as an individual task. If we have multiple CPUs/Cores or multiple machines available, we can render multiple frames in *parallel* to speed up the overall workload.

Q: What is a Mutex?

A **Mutex** is a mutually exclusive flag. It acts as a gate keeper to synchronise two threads. When you have two threads attempting to access a single resource, the general pattern is to have the first block of code attempting access, to set the _mutex_ before entering the code. When the second code block attempts access, it sees that the _mutex_ is set and waits until the first block of code is complete (and un-sets the mutex), then continues. Specific details of how this is accomplished obviously varies greatly by programming language. ![](https://www.keil.com/pack/doc/CMSIS/RTOS2/html/Mutex.png)

Q: Write a function that guarantees to never return the same value twice

1. Just toss a simple (threadsafe) counter behind some communication endpoint: ```java long x = long.MinValue; public long ID(){ return Interlocked.Increment(ref x); } ``` 2. Let interviewer be the one that follow up with those problems: * Does it need to survive reboots? * What about hard drive failure? * What about nuclear war? * Does it need to be random? * How random? 2. If they made it clear that it has to be unique across reboots and across different machines, I'd give them a function that calls into the standard mechanism for creating a new GUID, whatever that happens to be in the language being used. This is basically the problem that guids solve. Producing a duplicate Guid, no matter its format, is the most difficult lottery on the planet.

Q: What is the difference between Concurrency and Parallelism?

* **Concurrency** is when two or more tasks can start, run, and complete in overlapping time **periods**. It doesn't necessarily mean they'll ever both be running **at the same instant**. For example, *multitasking* on a single\-core machine. * **Parallelism** is when tasks *literally* run at the same time, e.g., on a multicore processor. For instance a bartender is able to look after several customers while he can only prepare one beverage at a time. So he can provide _concurrency without parallelism_.

Q: What is the meaning of the term “Thread-Safe”?

* **Thread-safe** code is code that will work even if many Threads are executing it simultaneously within the same process. This often means, that internal data-structures or operations that should run uninterrupted are protected against different modifications at the same time. * Another definition may be like - a class is** thread-safe** if it behaves correctly when accessed from multiple threads, regardless of the scheduling or interleaving of the execution of those threads by the runtime environment, and with no additional synchronisation or other coordination on the part of the calling code.

Q: How much work should I place inside a lock statement?

It is first and foremost a question of correctness. You should not care so much about efficiency trade-offs, but more about correctness. * Do as little work as possible while locking a particular object. Locks that are held for a long time are subject to contention, and contention is slow. Note that this implies that the *total* amount of code in a *particular* lock and the *total* amount of code in *all lock statements that lock on the same object* are both relevant. * Have as few locks as possible, to make the likelihood of deadlocks (or livelocks) lower. * If you want concurrency, use processes as your unit of concurrency. If you cannot use processes then use application domains. If you cannot use application domains, then have your threads managed by the Task Parallel Library and write your code in terms of high-level tasks (jobs) rather than low-level threads (workers). * Benchmarking and being aware that there are more options than "lock everything everywhere" and "lock only the bare minimum".

Q: Is there any difference between a Binary Semaphore and Mutex?

* A **mutex** (or Mutual Exclusion Semaphores) is a **locking mechanism** used to synchronize _access_ to a resource. Only one task (can be a thread or process based on OS abstraction) can acquire the mutex. It means there will be ownership associated with mutex, and only the owner can release the lock (mutex). * **Semaphore** (or Binary Semaphore) is **signaling mechanism** (“I am done, you can carry on” kind of signal). For example, if you are listening songs (assume it as one task) on your mobile and at the same time your friend called you, an interrupt will be triggered upon which an interrupt service routine (ISR) will signal the call processing task to wakeup. A binary semaphore is NOT protecting a resource from access. Semaphores are more suitable for some synchronization problems like producer-consumer. Short version: * A **mutex** can be released only by **the thread that had acquired it**. * A **binary semaphore** can be signaled **by any thread** (or process).

Q: Explain Deadlock to 5 years old

Jack and Jill share a sparse kitchen that has only one of everything. They both want to make a sandwich at the same time. Each needs a slice of bread and each needs a knife, so they both go to get the loaf of bread and the knife from the kitchen. Jack gets the knife first, while Jill gets the loaf of bread first. Now Jack tries to find the loaf of bread and Jill tries to find the knife, but both find that what they need to finish the task is already in use. If they both decide to wait until what they need is no longer in use, they will wait for each other forever. **Deadlock**.

Q: What is a Race Condition?

A race condition is a situation on concurrent programming where two concurrent threads or processes compete for a resource and the resulting final state depends on who gets the resource first. Because the thread scheduling algorithm can swap between threads at any time, you don't know the order in which the threads will attempt to access the shared data. Therefore, the result of the change in data is dependent on the thread scheduling algorithm, i.e. both threads are "racing" to access/change the data. Problems often occur when one thread does a "check-then-act" (e.g. "check" if the value is X, then "act" to do something that depends on the value being X) and another thread does something to the value in between the "check" and the "act". E.g: if (x == 5) // The "Check" { y = x * 2; // The "Act" // If another thread changed x in between "if (x == 5)" and "y = x * 2" above, // y will not be equal to 10. } The point being, y could be 10, or it could be anything, depending on whether another thread changed x in between the check and act. You have no real way of knowing. In order to prevent race conditions from occurring, you would typically put a lock (Mutex or Semaphores) around the shared data to ensure only one thread can access the data at a time. This would mean something like this: // Obtain lock for x if (x == 5) { y = x * 2; // Now, nothing can change x until the lock is released. // Therefore y = 10 } // release lock for x

Question 1

What is a Deadlock?

Accepted Answer

* A **lock** occurs when multiple processes try to access the same resource at the same time. One process loses out and must wait for the other to finish.

* A **deadlock** occurs when the waiting process is still holding on to another resource that the first needs before it can finish.

![](https://encrypted-tbn0.gstatic.com/images?q=tbn%3AANd9GcRLSs8hUDWsPkEkRsoaLbmQF2FHkNL9jPXjeg&usqp=CAU)

So, an example:

Resource A and resource B are used by process X and process Y

*   X starts to use A.
*   X and Y try to start using B
*   Y 'wins' and gets B first
*   now Y needs to use A
*   A is locked by X, which is waiting for Y

```
Thread 1               Thread 2

Lock1->Lock();         Lock2->Lock();
WaitForLock2();        WaitForLock1();   <-- Oops!
```

The best way to avoid deadlocks is to avoid having processes cross over in this way. Reduce the need to lock anything as much as you can. In databases avoid making lots of changes to different tables in a single transaction, avoid triggers and switch to optimistic/dirty/nolock reads as much as possible.

Question 2

Explain the difference between Asynchronous and Parallel programming?

Accepted Answer

When you run something **asynchronously** it means it is non\-blocking, you execute it without waiting for it to complete and carry on with other things. 
**Parallelism** means to run multiple things at the same time, in parallel. Parallelism works well when you can separate tasks into independent pieces of work. Async and Callbacks are generally a way (tool or mechanism) to express concurrency i.e. a set of entities possibly talking to each other and sharing resources.

Take for example rendering frames of a 3D animation. To render the animation takes a long time so if you were to launch that render from within your animation editing software you would make sure it was running *asynchronously* so it didn't lock up your UI and you could continue doing other things. Now, each frame of that animation can also be considered as an individual task. If we have multiple CPUs/Cores or multiple machines available, we can render multiple frames in *parallel* to speed up the overall workload.

Question 3

What is a Mutex?

Accepted Answer

A **Mutex** is a mutually exclusive flag. It acts as a gate keeper to synchronise two threads. When you have two threads attempting to access a single resource, the general pattern is to have the first block of code attempting access, to set the _mutex_ before entering the code. When the second code block attempts access, it sees that the _mutex_ is set and waits until the first block of code is complete (and un-sets the mutex), then continues.

Specific details of how this is accomplished obviously varies greatly by programming language.

![](https://www.keil.com/pack/doc/CMSIS/RTOS2/html/Mutex.png)

Question 4

Write a function that guarantees to never return the same value twice

Accepted Answer

1. Just toss a simple (threadsafe) counter behind some communication endpoint:

```java
long x = long.MinValue;
public long ID(){
    return Interlocked.Increment(ref x);
}
 ```
2. Let interviewer be the one that follow up with those problems:
 
   * Does it need to survive reboots? 
   * What about hard drive failure? 
   * What about nuclear war? 
   * Does it need to be random? 
   * How random?
2. If they made it clear that it has to be unique across reboots and across different machines, I'd give them a function that calls into the standard mechanism for creating a new GUID, whatever that happens to be in the language being used. This is basically the problem that guids solve. Producing a duplicate Guid, no matter its format, is the most difficult lottery on the planet.

Question 5

What is the difference between Concurrency and Parallelism?

Accepted Answer

* **Concurrency** is when two or more tasks can start, run, and complete in overlapping time **periods**. It doesn't necessarily mean they'll ever both be running **at the same instant**. For example, *multitasking* on a single\-core machine.

* **Parallelism** is when tasks *literally* run at the same time, e.g., on a multicore processor.

For instance a bartender is able to look after several customers while he can only prepare one beverage at a time. So he can provide _concurrency without parallelism_.

Question 6

What is the meaning of the term “Thread-Safe”?

Accepted Answer

* **Thread-safe** code is code that will work even if many Threads are executing it simultaneously within the same process. This often means, that internal data-structures or operations that should run uninterrupted are protected against different modifications at the same time.
* Another definition may be like - a class is** thread-safe** if it behaves correctly when accessed from multiple threads, regardless of the scheduling or interleaving of the execution of those threads by the runtime environment, and with no additional synchronisation or other coordination on the part of the calling code.

Question 7

How much work should I place inside a lock statement?

Accepted Answer

It is first and foremost a question of correctness. You should not care so much about efficiency trade-offs, but more about correctness.

*   Do as little work as possible while locking a particular object. Locks that are held for a long time are subject to contention, and contention is slow. Note that this implies that the *total* amount of code in a *particular* lock and the *total* amount of code in *all lock statements that lock on the same object* are both relevant.
*   Have as few locks as possible, to make the likelihood of deadlocks (or livelocks) lower.
*  If you want concurrency, use processes as your unit of concurrency. If you cannot use processes then use application domains. If you cannot use application domains, then have your threads managed by the Task Parallel Library and write your code in terms of high-level tasks (jobs) rather than low-level threads (workers).
* Benchmarking and being aware that there are more options than "lock everything everywhere" and "lock only the bare minimum".

Question 8

Is there any difference between a Binary Semaphore and Mutex?

Accepted Answer

* A **mutex** (or Mutual Exclusion Semaphores) is a **locking mechanism** used to synchronize _access_ to a resource. Only one task (can be a thread or process based on OS abstraction) can acquire the mutex. It means there will be ownership associated with mutex, and only the owner can release the lock (mutex).

* **Semaphore** (or Binary Semaphore) is **signaling mechanism** (“I am done, you can carry on” kind of signal). For example, if you are listening songs (assume it as one task) on your mobile and at the same time your friend called you, an interrupt will be triggered upon which an interrupt service routine (ISR) will signal the call processing task to wakeup. A binary semaphore is NOT protecting a resource from access. Semaphores are more suitable for some synchronization problems like producer-consumer.

Short version:
*   A **mutex** can be released only by **the thread that had acquired it**.
*   A **binary semaphore** can be signaled **by any thread** (or process).

Question 9

Explain Deadlock to 5 years old

Accepted Answer

Jack and Jill share a sparse kitchen that has only one of everything. They both want to make a sandwich at the same time. Each needs a slice of bread and each needs a knife, so they both go to get the loaf of bread and the knife from the kitchen.

Jack gets the knife first, while Jill gets the loaf of bread first. Now Jack tries to find the loaf of bread and Jill tries to find the knife, but both find that what they need to finish the task is already in use. If they both decide to wait until what they need is no longer in use, they will wait for each other forever. **Deadlock**.

Question 10

What is a Race Condition?

Accepted Answer

A race condition is a situation on concurrent programming where two concurrent threads or processes compete for a resource and the resulting final state depends on who gets the resource first.

Because the thread scheduling algorithm can swap between threads at any time, you don't know the order in which the threads will attempt to access the shared data. Therefore, the result of the change in data is dependent on the thread scheduling algorithm, i.e. both threads are "racing" to access/change the data.

Problems often occur when one thread does a "check-then-act" (e.g. "check" if the value is X, then "act" to do something that depends on the value being X) and another thread does something to the value in between the "check" and the "act". E.g:

if (x == 5) // The "Check"
    {
       y = x * 2; // The "Act"

// If another thread changed x in between "if (x == 5)" and "y = x * 2" above,
       // y will not be equal to 10.
    }

The point being, y could be 10, or it could be anything, depending on whether another thread changed x in between the check and act. You have no real way of knowing.

In order to prevent race conditions from occurring, you would typically put a lock (Mutex or Semaphores) around the shared data to ensure only one thread can access the data at a time. This would mean something like this:

// Obtain lock for x
    if (x == 5)
    {
       y = x * 2; // Now, nothing can change x until the lock is released. 
                  // Therefore y = 10
    }
    // release lock for x

Top 21 Concurrency Interview Questions

What is a Mutex?

Explain the difference between Asynchronous and Parallel programming?

What is a Deadlock?

What is the difference between Concurrency and Parallelism?

Is there any difference between a Binary Semaphore and Mutex?

What is a Race Condition?

How much work should I place inside a lock statement?

Write a function that guarantees to never return the same value twice

Explain Deadlock to 5 years old

What is the meaning of the term “Thread-Safe”?

What is Starvation?

Compare Actor Model with Threading Model for concurrency

Two customers add a product to the basket in the same time whose the stock was only one (1). What will you do?

Provide some real-live examples of Livelock

Explain what is a Race Condition to 5 years old

What's the difference between Deadlock and Livelock?

What is a Data Race?

What is Green Thread?

What are some advantages of Lockless Concurrency?

What is the difference between Race Condition and Data Races? Are they the same?

What happens if you have a "race condition" on the lock itself?