From: Gunjan Sharma <gunjan@fb.com>
Date: Thu, 10 Jul 2014 00:50:19 +0000 (-0700)
Subject: Fix another race in Notification Queue
X-Git-Tag: v0.22.0~456
X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=c765dfdffc042b6c6d9a871bdeb31389f68fac5c;p=folly.git

Fix another race in Notification Queue

Summary: Consider a case we found that the queue is empty and unlocked and before our setActive(false) from SCOPE_EXIT gets called (or gets the lock) putMessageImpl got the lock. Now putMessage thinks that we donot want to add another signal but actually we do.

Test Plan:
Running mcreplay2 without running into this problem on a box.
Benchmark:

Reviewed By: davejwatson@fb.com

FB internal diff: D1428249
---

diff --git a/folly/io/async/NotificationQueue.h b/folly/io/async/NotificationQueue.h
index d0afd3e4..c06f3e84 100644
--- a/folly/io/async/NotificationQueue.h
+++ b/folly/io/async/NotificationQueue.h
@@ -576,6 +576,7 @@ void NotificationQueue<MessageT>::Consumer::handlerReady(uint16_t events)
     try {
       if (UNLIKELY(queue_->queue_.empty())) {
         // If there is no message, we've reached the end of the queue, return.
+        setActive(false);
         queue_->spinlock_.unlock();
         return;
       }