October 29, 2008
Writing a Generalized Concurrent QueueProduce
Now let's look at the first of the two key methods: Produce. The goal is to allow multiple producers, and to let them run as concurrently as possible:
First, we want to do as much work as possible outside the critical section of code that actually updates the queue. In this case, we can do all of the allocation and construction of the new node and its value concurrently with any number of other producers and consumers.
Second, we "commit" the change by getting exclusive access to the tail of the queue. The while loop keeps trying to set the producerLock to true until the old value was false because while the old value was true, it means someone else already has exclusivity. The way to read this while loop is, "until I get to be the one to change producerLock from false to true," which means that this thread has acquired exclusivity. Then we can update last->next and last itself, which are two separate writes and cannot be done as a single atomic operation on most processors without some sort of lock. Finally, we release exclusivity on the tail of the queue by setting producerLock to false.
Consume
Likewise, we want to support any number of threads calling Consume, and let them run as concurrently as possible. First, we get exclusivity, this time on the head end of the queue:
Next, we read the head node's next pointer. If it's not null, we need to take out the first value but we want to do as little work as possible here inside the exclusive critical section:
Now we're done touching the list, and other consumers can make progress while we do the remaining copying and cleanup work off to the side:
Otherwise, if theNext was null, the list was empty and we can immediately release exclusion and return that status:
consumerLock = false; // release exclusivity
return false; // report queue was empty
}
};
|
|
||||||||||||||||||||||||||||||
|
|
|
|