开发者

Condition Variable Along with Mutex

开发者 https://www.devze.com 2023-04-01 10:03 出处:网络
A bit of confusion! What could be the problem if we look at the following scenario: My ob开发者_运维问答jective is to understand the mixture of condition variable with mutex.

A bit of confusion! What could be the problem if we look at the following scenario: My ob开发者_运维问答jective is to understand the mixture of condition variable with mutex.

T1

  1. LOCK { MUTEX }
  2. CHECK VARIABLE
  3. IF NOT SET, WAIT ON CONDITION VARIABLE
  4. UNLOCK {MUTEX} GO TO 1

T2

  1. MODIFY VARIABLE;
  2. SIGNAL CONDITION VARIABLE

There could be race condition between step 2. and 3., hence we use MUTEX. What I do not understand is the underlying idea of cond var + mutex.


There are two problems with omitting the lock on the write end:

  1. If your variable you're modifying cannot be written to atomically (ie, it's larger than an int - although the details depend on the CPU architecture you're using!), you need a lock to ensure you don't have "shearing". This is when a read occurs when the variable is partway written. For example, you could write 0xAAAAAAAABBBBBBBB to a 64-bit variable that was previously 0, and another thread might only see 0xAAAAAAAA00000000 or 0x00000000BBBBBBBB. The lock prevents readers from seeing the in-progress write, avoiding this problem.
  2. It's possible that the reader may see your variable in the still-need-to-wait state, then before it can go to sleep, the writer could update the variable and signal the condition variable. As a result, your thread goes to sleep forever. Taking the lock on the write side prevents this from occuring.

Note also that many uses of condition variables do more than just modifying a flag in the lock - they may manipulate linked lists, for example, or some other complex data structure. In this case, the lock is needed to protect that data structure, as well as for the condition variable.


I'm taking some guesses about your context and the behavior you want, but I think that you want things to look like this:

T1:
1. lock mutex
2. check variable
3. unlock mutex
4. wait on condition variable
5. goto 1

T2:
1. lock mutex
2. modify variable
3. unlock mutex
4. signal condition variable

The mutex is to protect access to the variable so that you don't have different threads reading and writing to it all at the same time.

The condition variable is used to synchronize threads so that you can control the order in which things happen.


You're doing it wrong. condition variables have a mutex associated with them. You need to lock the mutex before changing the variable and releasing it afterwards.

There is no dead lock - pthread_cond_wait gets the associated mutex as parameter exactly because so it can unlock the mutex when you are block in a race free manner (it releases the mutex when you are on the waiters queue for the condition variable, so that you are granteed to be awaken when the condition variable is signaled.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号