Download
Skip this Video
1 / 65
Concurrent Queues - PowerPoint PPT Presentation
- By lance
- Follow User
- 108 Views
- Uploaded on
Concurrent Queues. שירן חליבה. Outline:. Some definitions 3 queue implementations : A Bounded Partial Queue An Unbounded Total Queue An Unbounded Lock-Free Queue. Introduction and some definitions: .
Download Presentation 
An Image/Link below is provided (as is) to download presentation
PowerPoint Slideshow about 'Concurrent Queues' - lance
An Image/Link below is provided (as is) to download presentation
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.
While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Concurrent Queues
שירן חליבה
Outline:
- Some definitions
- 3 queue implementations :
- A Bounded Partial Queue
- An Unbounded Total Queue
- An Unbounded Lock-Free Queue
Introduction and some definitions:
- Pools show up in many places in concurrent systems. Forexample, in many applications, one or more producer threads produce items to beconsumed by one or more consumer threads.
- To allow consumers to keep up, we can place a bufferbetween the producers and the consumers.
- Often, pools act as producer–consumer buffers.
- A pool allows the same item to appear more than once.
Introduction and some definitions cont.
- A queue is a special kind of pool with FIFO fairness.
- Itprovides an enq(x) method that puts item x at one end of the queue, called thetail, and a deq() method that removes and returns the item at the other end of thequeue, called the head.
Bounded vs. Unbounded
- A pool can be bounded or unbounded.
- Bounded
- Fixed capacity
- Good when resources an issue
- Unbounded
- Holds any number of objects
Blocking vs. Non-Blocking
- Problem cases:
- Removing from empty pool
- Adding to full (bounded) pool
- Blocking
- Caller waits until state changes
- Non-Blocking
- Method throws exception
Total vs. Partial
- Pool methods may be total or partial.
- A method is total if calls do not wait for certain conditions to become true. For example, a get() call that tries to remove an item from an empty pool immediately returns a failure code or throws an exception. A total interface makes sense whenthe producer (or consumer) thread has something better to do than waitfor the method call to take effect.
Total vs. Partial
- A method is partial if calls may wait for conditions to hold. For example, a partial get() call that tries to remove an item from an empty pool blocks until an item is available to return. A partial interface makes sense when the producer (or consumer) has nothing better to do than to wait for the pool to become nonempty (or non full).
A Bounded Partial Queue
Sentinel
First actual item
head
tail
deqLock
Lock out other deq() calls
enqLock
Lock out other enq() calls
permits
8
Permission to enqueue 8 items
Dequeuer
head
tail
deqLock
enqLock
Increment permits
(no need lock?)
permits
8
Answer: we had to hold the lock while enqueuing to prevent lots of enqueuers from proceeding without noticing that the capacity had been exceeded. Dequeuers will notice the queue is empty when they observe that the sentinel’s next field is null
public class BoundedQueue<T> {
ReentrantLock enqLock, deqLock;
Condition notEmptyCondition, notFullCondition;
AtomicInteger permits;
Node head;
Node tail;
int capacity;
enqLock = new ReentrantLock();
notFullCondition = enqLock.newCondition();
deqLock = new ReentrantLock();
notEmptyCondition = deqLock.newCondition();
}
The ReentrantLock is a monitor (The mechanism that Java uses to support synchronization ). Allows blocking on a condition rather than spinning.How do we use it?(*More on monitors: http://www.artima.com/insidejvm/ed2/threadsynch.html)
Lock Conditions
public interface Condition {
void await();
boolean await(long time, TimeUnit unit);
…
void signal();
void signalAll();
}
Await
- Releases lock associated with q
- Sleeps (gives up processor)
- Awakens (resumes running)
- Reacquires lock & returns
q.await()
Monitor Signalling
Yawn!
Yawn!
waiting room
Critical Section
Awakend thread
might still lose lock to
outside contender…
Enq Method
public void enq(T x) {
boolean mustWakeDequeuers = false;
enqLock.lock();
try {
while (permits.get() == 0)
notFullCondition.await();
Node e = new Node(x);
tail.next = e;
tail = e;
if (permits.getAndDecrement() == capacity)
mustWakeDequeuers = true;
} finally {
enqLock.unlock();
}
…
}
Cont…
public void enq(T x) {
…
if (mustWakeDequeuers) {
deqLock.lock();
try {
notEmptyCondition.signalAll();
} finally {
deqLock.unlock();
}
}
}
The Enq() & Deq() Methods
- Share no locks
- That’s good
- But do share an atomic counter
- Accessed on every method call
- That’s not so good
- Can we alleviate this bottleneck?
What is the problem?
Split the Counter
- The enq() method
- Decrements only
- Cares only if value is zero
- The deq() method
- Increments only
- Cares only if value is capacity
Split Counter
- Enqueuer decrements enqSidePermits
- Dequeuer increments deqSidePermits
- When enqueuer runs out
- Locks deqLock
- Transfers permits
- (dequeuer doesn't need permits- check head.next)
- Intermittent(תקופתי) synchronization
- Not with each method call
- Need both locks! (careful …)
An Unbounded Total Queue
- Queue can hold an unbounded number of items.
- The enq() method always enqueues its item.
- The deq() throws EmptyException if there is no item to dequeue.
- No deadlock- each method acquires only one lock.
- Both the enq() and deq() methods are total as they do not wait for the queue to become empty or full.
A Lock-Free Queue
Sentinel
head
tail
- Extension of the unbounded total queue
- Quicker threads help the slower threads
- Each node’s next field is an:
- AtomicReference<Node>
- The queue itself consists of two
- AtomicReference<Node> fields:
- head and tail
Enqueue
- These two steps are not atomic
- The tail field refers to either
- Actual last Node (good)
- Penultimate* Node (not so good)
- Be prepared!
(*Penultimate :next to the last)
Enqueue
- What do you do if you find
- A trailing tail?
- Stop and fix it
- If tail node has non-null next field
- CAS the queue’s tail field to tail.next
When CASs Fail
- During logical enqueue
- Abandon hope, restart
- During physical enqueue
- Ignore it (why?)
Enq()
- Creates a new node with the new value to be enqueued
- reads tail, and finds the node that appears to be last
- checks whether that node has a successor
- If not - appends the new node by calling compareAndSet()
- If the compareAndSet() succeeds, the thread uses a second compareAndSet() to advance tail to the new node
- second compareAndSet() call fails, the thread can still return successfully
- If the tail node has a successor , then the method tries to “help”other threads by advancing tail to refer directly to the successor before trying again to insert its own node.
Deq()
- If the queue is nonempty(the next field of the head node is not null), the dequeuer calls compareAndSet() to change head from the sentinel node to its successor
- before advancing head one must make sure that tail is not left referring to the sentinel node which is about to be removed from the queue
- test: if head equals tail and the (sentinel) node they refer to has a non-null next field, then the tail is deemed to be lagging behind.
- deq() then attempts to help make tail consistent by swinging it to the sentinel node’s successor , and only then updates head to remove the sentinel
Summary
- A thread fails to enqueue or dequeue a node only if another thread’s method call succeeds in changing the reference, so some method call always completes.
- As it turns out, being lock-free substantially enhances the performance of queue implementations, and the lock-free algorithms tend to outperform the most efficient blocking ones.
