folly/synchronization/Baton.h

   1 /*
   2  * Copyright 2017 Facebook, Inc.
   3  *
   4  * Licensed under the Apache License, Version 2.0 (the "License");
   5  * you may not use this file except in compliance with the License.
   6  * You may obtain a copy of the License at
   7  *
   8  *   http://www.apache.org/licenses/LICENSE-2.0
   9  *
  10  * Unless required by applicable law or agreed to in writing, software
  11  * distributed under the License is distributed on an "AS IS" BASIS,
  12  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  13  * See the License for the specific language governing permissions and
  14  * limitations under the License.
  15  */
  16
  17 #pragma once
  18
  19 #include <assert.h>
  20 #include <errno.h>
  21 #include <stdint.h>
  22 #include <atomic>
  23 #include <thread>
  24
  25 #include <folly/Likely.h>
  26 #include <folly/detail/Futex.h>
  27 #include <folly/detail/MemoryIdler.h>
  28 #include <folly/portability/Asm.h>
  29
  30 namespace folly {
  31
  32 /// A Baton allows a thread to block once and be awoken. Captures a
  33 /// single handoff, and during its lifecycle (from construction/reset
  34 /// to destruction/reset) a baton must either be post()ed and wait()ed
  35 /// exactly once each, or not at all.
  36 ///
  37 /// Baton includes no internal padding, and is only 4 bytes in size.
  38 /// Any alignment or padding to avoid false sharing is up to the user.
  39 ///
  40 /// This is basically a stripped-down semaphore that supports only a
  41 /// single call to sem_post and a single call to sem_wait.
  42 ///
  43 /// The non-blocking version (Blocking == false) provides more speed
  44 /// by using only load acquire and store release operations in the
  45 /// critical path, at the cost of disallowing blocking and timing out.
  46 ///
  47 /// The current posix semaphore sem_t isn't too bad, but this provides
  48 /// more a bit more speed, inlining, smaller size, a guarantee that
  49 /// the implementation won't change, and compatibility with
  50 /// DeterministicSchedule.  By having a much more restrictive
  51 /// lifecycle we can also add a bunch of assertions that can help to
  52 /// catch race conditions ahead of time.
  53 template <
  54     template <typename> class Atom = std::atomic,
  55     bool Blocking = true> // blocking vs spinning
  56 struct Baton {
  57   constexpr Baton() : state_(INIT) {}
  58
  59   Baton(Baton const&) = delete;
  60   Baton& operator=(Baton const&) = delete;
  61
  62   /// It is an error to destroy a Baton on which a thread is currently
  63   /// wait()ing.  In practice this means that the waiter usually takes
  64   /// responsibility for destroying the Baton.
  65   ~Baton() {
  66     // The docblock for this function says that it can't be called when
  67     // there is a concurrent waiter.  We assume a strong version of this
  68     // requirement in which the caller must _know_ that this is true, they
  69     // are not allowed to be merely lucky.  If two threads are involved,
  70     // the destroying thread must actually have synchronized with the
  71     // waiting thread after wait() returned.  To convey causality the the
  72     // waiting thread must have used release semantics and the destroying
  73     // thread must have used acquire semantics for that communication,
  74     // so we are guaranteed to see the post-wait() value of state_,
  75     // which cannot be WAITING.
  76     //
  77     // Note that since we only care about a single memory location,
  78     // the only two plausible memory orders here are relaxed and seq_cst.
  79     assert(state_.load(std::memory_order_relaxed) != WAITING);
  80   }
  81
  82   /// Equivalent to destroying the Baton and creating a new one.  It is
  83   /// a bug to call this while there is a waiting thread, so in practice
  84   /// the waiter will be the one that resets the baton.
  85   void reset() {
  86     // See ~Baton for a discussion about why relaxed is okay here
  87     assert(state_.load(std::memory_order_relaxed) != WAITING);
  88
  89     // We use a similar argument to justify the use of a relaxed store
  90     // here.  Since both wait() and post() are required to be called
  91     // only once per lifetime, no thread can actually call those methods
  92     // correctly after a reset() unless it synchronizes with the thread
  93     // that performed the reset().  If a post() or wait() on another thread
  94     // didn't synchronize, then regardless of what operation we performed
  95     // here there would be a race on proper use of the Baton's spec
  96     // (although not on any particular load and store).  Put another way,
  97     // we don't need to synchronize here because anybody that might rely
  98     // on such synchronization is required by the baton rules to perform
  99     // an additional synchronization that has the desired effect anyway.
 100     //
 101     // There is actually a similar argument to be made about the
 102     // constructor, in which the fenceless constructor initialization
 103     // of state_ is piggybacked on whatever synchronization mechanism
 104     // distributes knowledge of the Baton's existence
 105     state_.store(INIT, std::memory_order_relaxed);
 106   }
 107
 108   /// Causes wait() to wake up.  For each lifetime of a Baton (where a
 109   /// lifetime starts at construction or reset() and ends at
 110   /// destruction or reset()) there can be at most one call to post(),
 111   /// in the single poster version.  Any thread may call post().
 112   void post() {
 113     if (!Blocking) {
 114       /// Non-blocking version
 115       ///
 116       assert([&] {
 117         auto state = state_.load(std::memory_order_relaxed);
 118         return (state == INIT || state == EARLY_DELIVERY);
 119       }());
 120       state_.store(EARLY_DELIVERY, std::memory_order_release);
 121       return;
 122     }
 123
 124     /// Blocking versions
 125     ///
 126     uint32_t before = state_.load(std::memory_order_acquire);
 127
 128     assert(before == INIT || before == WAITING || before == TIMED_OUT);
 129
 130     if (before == INIT &&
 131         state_.compare_exchange_strong(before, EARLY_DELIVERY)) {
 132       return;
 133     }
 134
 135     assert(before == WAITING || before == TIMED_OUT);
 136
 137     if (before == TIMED_OUT) {
 138       return;
 139     }
 140
 141     assert(before == WAITING);
 142     state_.store(LATE_DELIVERY, std::memory_order_release);
 143     state_.futexWake(1);
 144   }
 145
 146   /// Waits until post() has been called in the current Baton lifetime.
 147   /// May be called at most once during a Baton lifetime (construction
 148   /// |reset until destruction|reset).  If post is called before wait in
 149   /// the current lifetime then this method returns immediately.
 150   ///
 151   /// The restriction that there can be at most one wait() per lifetime
 152   /// could be relaxed somewhat without any perf or size regressions,
 153   /// but by making this condition very restrictive we can provide better
 154   /// checking in debug builds.
 155   FOLLY_ALWAYS_INLINE void wait() {
 156     if (try_wait()) {
 157       return;
 158     }
 159
 160     waitSlow();
 161   }
 162
 163   /// Similar to wait, but doesn't block the thread if it hasn't been posted.
 164   ///
 165   /// try_wait has the following semantics:
 166   /// - It is ok to call try_wait any number times on the same baton until
 167   ///   try_wait reports that the baton has been posted.
 168   /// - It is ok to call timed_wait or wait on the same baton if try_wait
 169   ///   reports that baton hasn't been posted.
 170   /// - If try_wait indicates that the baton has been posted, it is invalid to
 171   ///   call wait, try_wait or timed_wait on the same baton without resetting
 172   ///
 173   /// @return       true if baton has been posted, false othewise
 174   FOLLY_ALWAYS_INLINE bool try_wait() const {
 175     auto s = state_.load(std::memory_order_acquire);
 176     assert(s == INIT || s == EARLY_DELIVERY);
 177     return LIKELY(s == EARLY_DELIVERY);
 178   }
 179
 180   /// Similar to wait, but with a timeout. The thread is unblocked if the
 181   /// timeout expires.
 182   /// Note: Only a single call to wait/try_wait_for/try_wait_until is allowed
 183   /// during a baton's life-cycle (from ctor/reset to dtor/reset). In other
 184   /// words, after try_wait_for the caller can't invoke
 185   /// wait/try_wait/try_wait_for/try_wait_until
 186   /// again on the same baton without resetting it.
 187   ///
 188   /// @param  timeout       Time until which the thread can block
 189   /// @return               true if the baton was posted to before timeout,
 190   ///                       false otherwise
 191   template <typename Rep, typename Period>
 192   FOLLY_ALWAYS_INLINE bool try_wait_for(
 193       const std::chrono::duration<Rep, Period>& timeout) {
 194     static_assert(
 195         Blocking, "Non-blocking Baton does not support try_wait_for.");
 196
 197     if (try_wait()) {
 198       return true;
 199     }
 200
 201     auto deadline = std::chrono::steady_clock::now() + timeout;
 202     return tryWaitUntilSlow(deadline);
 203   }
 204
 205   /// Similar to wait, but with a deadline. The thread is unblocked if the
 206   /// deadline expires.
 207   /// Note: Only a single call to wait/try_wait_for/try_wait_until is allowed
 208   /// during a baton's life-cycle (from ctor/reset to dtor/reset). In other
 209   /// words, after try_wait_until the caller can't invoke
 210   /// wait/try_wait/try_wait_for/try_wait_until
 211   /// again on the same baton without resetting it.
 212   ///
 213   /// @param  deadline      Time until which the thread can block
 214   /// @return               true if the baton was posted to before deadline,
 215   ///                       false otherwise
 216   template <typename Clock, typename Duration>
 217   FOLLY_ALWAYS_INLINE bool try_wait_until(
 218       const std::chrono::time_point<Clock, Duration>& deadline) {
 219     static_assert(
 220         Blocking, "Non-blocking Baton does not support try_wait_until.");
 221
 222     if (try_wait()) {
 223       return true;
 224     }
 225
 226     return tryWaitUntilSlow(deadline);
 227   }
 228
 229   /// Alias to try_wait_for. Deprecated.
 230   template <typename Rep, typename Period>
 231   FOLLY_ALWAYS_INLINE bool timed_wait(
 232       const std::chrono::duration<Rep, Period>& timeout) {
 233     return try_wait_for(timeout);
 234   }
 235
 236   /// Alias to try_wait_until. Deprecated.
 237   template <typename Clock, typename Duration>
 238   FOLLY_ALWAYS_INLINE bool timed_wait(
 239       const std::chrono::time_point<Clock, Duration>& deadline) {
 240     return try_wait_until(deadline);
 241   }
 242
 243  private:
 244   enum State : uint32_t {
 245     INIT = 0,
 246     EARLY_DELIVERY = 1,
 247     WAITING = 2,
 248     LATE_DELIVERY = 3,
 249     TIMED_OUT = 4,
 250   };
 251
 252   enum {
 253     // Must be positive.  If multiple threads are actively using a
 254     // higher-level data structure that uses batons internally, it is
 255     // likely that the post() and wait() calls happen almost at the same
 256     // time.  In this state, we lose big 50% of the time if the wait goes
 257     // to sleep immediately.  On circa-2013 devbox hardware it costs about
 258     // 7 usec to FUTEX_WAIT and then be awoken (half the t/iter as the
 259     // posix_sem_pingpong test in BatonTests).  We can improve our chances
 260     // of EARLY_DELIVERY by spinning for a bit, although we have to balance
 261     // this against the loss if we end up sleeping any way.  Spins on this
 262     // hw take about 7 nanos (all but 0.5 nanos is the pause instruction).
 263     // We give ourself 300 spins, which is about 2 usec of waiting.  As a
 264     // partial consolation, since we are using the pause instruction we
 265     // are giving a speed boost to the colocated hyperthread.
 266     PreBlockAttempts = 300,
 267   };
 268
 269   // Spin for "some time" (see discussion on PreBlockAttempts) waiting
 270   // for a post.
 271   //
 272   // @return       true if we received an early delivery during the wait,
 273   //               false otherwise. If the function returns true then
 274   //               state_ is guaranteed to be EARLY_DELIVERY
 275   bool spinWaitForEarlyDelivery() {
 276     static_assert(
 277         PreBlockAttempts > 0,
 278         "isn't this assert clearer than an uninitialized variable warning?");
 279     for (int i = 0; i < PreBlockAttempts; ++i) {
 280       if (try_wait()) {
 281         return true;
 282       }
 283
 284       // The pause instruction is the polite way to spin, but it doesn't
 285       // actually affect correctness to omit it if we don't have it.
 286       // Pausing donates the full capabilities of the current core to
 287       // its other hyperthreads for a dozen cycles or so
 288       asm_volatile_pause();
 289     }
 290
 291     return false;
 292   }
 293
 294   FOLLY_NOINLINE void waitSlow() {
 295     if (spinWaitForEarlyDelivery()) {
 296       assert(state_.load(std::memory_order_acquire) == EARLY_DELIVERY);
 297       return;
 298     }
 299
 300     if (!Blocking) {
 301       while (!try_wait()) {
 302         std::this_thread::yield();
 303       }
 304       return;
 305     }
 306
 307     // guess we have to block :(
 308     uint32_t expected = INIT;
 309     if (!state_.compare_exchange_strong(expected, WAITING)) {
 310       // CAS failed, last minute reprieve
 311       assert(expected == EARLY_DELIVERY);
 312       return;
 313     }
 314
 315     while (true) {
 316       detail::MemoryIdler::futexWait(state_, WAITING);
 317
 318       // state_ is the truth even if FUTEX_WAIT reported a matching
 319       // FUTEX_WAKE, since we aren't using type-stable storage and we
 320       // don't guarantee reuse.  The scenario goes like this: thread
 321       // A's last touch of a Baton is a call to wake(), which stores
 322       // LATE_DELIVERY and gets an unlucky context switch before delivering
 323       // the corresponding futexWake.  Thread B sees LATE_DELIVERY
 324       // without consuming a futex event, because it calls futexWait
 325       // with an expected value of WAITING and hence doesn't go to sleep.
 326       // B returns, so the Baton's memory is reused and becomes another
 327       // Baton (or a reuse of this one).  B calls futexWait on the new
 328       // Baton lifetime, then A wakes up and delivers a spurious futexWake
 329       // to the same memory location.  B's futexWait will then report a
 330       // consumed wake event even though state_ is still WAITING.
 331       //
 332       // It would be possible to add an extra state_ dance to communicate
 333       // that the futexWake has been sent so that we can be sure to consume
 334       // it before returning, but that would be a perf and complexity hit.
 335       uint32_t s = state_.load(std::memory_order_acquire);
 336       assert(s == WAITING || s == LATE_DELIVERY);
 337
 338       if (s == LATE_DELIVERY) {
 339         return;
 340       }
 341       // retry
 342     }
 343   }
 344
 345   template <typename Clock, typename Duration>
 346   FOLLY_NOINLINE bool tryWaitUntilSlow(
 347       const std::chrono::time_point<Clock, Duration>& deadline) {
 348     if (spinWaitForEarlyDelivery()) {
 349       assert(state_.load(std::memory_order_acquire) == EARLY_DELIVERY);
 350       return true;
 351     }
 352
 353     // guess we have to block :(
 354     uint32_t expected = INIT;
 355     if (!state_.compare_exchange_strong(expected, WAITING)) {
 356       // CAS failed, last minute reprieve
 357       assert(expected == EARLY_DELIVERY);
 358       return true;
 359     }
 360
 361     while (true) {
 362       auto rv = state_.futexWaitUntil(WAITING, deadline);
 363       if (rv == folly::detail::FutexResult::TIMEDOUT) {
 364         state_.store(TIMED_OUT, std::memory_order_release);
 365         return false;
 366       }
 367
 368       uint32_t s = state_.load(std::memory_order_acquire);
 369       assert(s == WAITING || s == LATE_DELIVERY);
 370       if (s == LATE_DELIVERY) {
 371         return true;
 372       }
 373     }
 374   }
 375
 376   detail::Futex<Atom> state_;
 377 };
 378
 379 } // namespace folly