From c765dfdffc042b6c6d9a871bdeb31389f68fac5c Mon Sep 17 00:00:00 2001 From: Gunjan Sharma Date: Wed, 9 Jul 2014 17:50:19 -0700 Subject: [PATCH] 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 --- folly/io/async/NotificationQueue.h | 1 + 1 file changed, 1 insertion(+) 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::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; } -- 2.34.1