Summary: [Folly] `PriorityUnboundedQueueSet`, wrapping `UnboundedQueue`.

Reviewed By: andriigrynenko

Differential Revision: D14719777

fbshipit-source-id: 529ddd8de5879908e36f6fc26e7a091230cb03da

Summary:
```
folly/io/async/test/AsyncTimeoutTest.cpp: In lambda function:
folly/io/async/test/AsyncTimeoutTest.cpp:31:70: internal compiler error: Segmentation fault
       AsyncTimeout::make(manager, [&]() noexcept { value = expected; });
                                                                      ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
```

I'm using:

```
 $ /opt/rh/devtoolset-8/root/usr/bin/c++ --version
c++ (GCC) 8.2.1 20180801 (Red Hat 8.2.1-2)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

This has been fixed in gcc 8.3, but the workaround is to explicitly
name the captures as is done in this diff.

Reviewed By: yfeldblum

Differential Revision: D14702587

fbshipit-source-id: 1998ef5de8eb4df520edcc41fdc9cd9547dec824

Summary:
I finally got to the bottom of the weird `-levent` or `event.lib`
linker errors that crop up in the cmake builds.

The issue is that if you have installed a recent libevent it deploys
a cmake CONFIG package that exports just a bare `event` target as the
dep on libevent.  This is unfortunate because it is interpreted as
meaning `-levent` with no library path, which for an installation
of libevent that is not in the default path will result in linker
errors in libraries downstream of folly.

To resolve this, I've given the common `FindLibEvent.cmake` file
(that was derived from the folly library of the same name) a similar
treatment to the recent changes to find glog and taught it how to
locate libevent from a config package and to fall back on a basic
include/library check.

If we find an `event` target then we extract the actual library
path from it and export that.

I've removed folly's and wangle's own FindLibEvent.cmake so that it will pick
up the common library which gets shipit sync'd out to
https://github.com/facebook/folly/blob/master/CMake/FindLibEvent.cmake
and https://github.com/facebook/wangle/blob/master/build/fbcode_builder/CMake/FindLibEvent.cmake

Reviewed By: yfeldblum

Differential Revision: D14702577

fbshipit-source-id: d35d9f741e009dcd77976c0637ba3024a8a4aef3

Summary:
```
folly/experimental/test/FutureDAGTest.cpp:46:7: error: ‘source_node’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
       if (it->first != source_node) {
       ^~
cc1plus: all warnings being treated as errors
```

Reviewed By: yfeldblum

Differential Revision: D14702569

fbshipit-source-id: 949ecde007a8d84498c5d87f4a4c2db463ba83a9

Summary:
```
folly/folly/io/test/IOBufCursorTest.cpp:212:3:
folly/folly/io/Cursor.h:411:13: error: ‘void* memcpy(void*, const void
*, size_t)’ forming offset [13, 20] is out of the bounds [0, 12] of object ‘buf’ with type ‘char [12]’ [-Werror=array-bounds]
       memcpy(buf, data(), len);
       ~~~~~~^~~~~~~~~~~~~~~~~~
```

Reviewed By: yfeldblum

Differential Revision: D14702563

fbshipit-source-id: 3697a021d71bccfae9d8833b42a0c25e916b7a78

Summary:
```
folly/experimental/test/LockFreeRingBufferTest.cpp:279:14: error
: ‘char* strncpy(char*, const char*, size_t)’ output may be truncated copying 1023 bytes from a string of length 1023 [-Werror=stringop-truncation]
       strncpy(data_, data.data_, sizeof(data_) - 1);
       ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

Reviewed By: yfeldblum

Differential Revision: D14702561

fbshipit-source-id: 8f85c758c7afc99eeb1f95920511fb4195eafbbe

Summary:
Making the `co_scoped_lock()` and `co_lock()` operations semi-awatitable forces the caller to provide an executor on which to resume the awaiting coroutine in the case that the lock could not be acquire synchronously.

This improves the safety of folly::coro::Mutex when used from within an InlineTask which does not implicitly wrap all co_await expressions to ensure transitions back to the executor and would otherwise implicitly resume the next lock-acquirer inline inside the call to .unlock().

Reviewed By: andriigrynenko

Differential Revision: D14708636

fbshipit-source-id: bb9cda1a4a6e53978071a7b98ebf9affeef47c7d

Summary:
- Instead of defining a separate `assume_unreachable` wrapper macro for
  support on different compilers, use the one directly from
  `folly/lang/Assume.h` which is spelled `folly::assume_unreachable`.
- Since the `assume_unreachable` wrapper in `FBString.h` was the only
  thing using FBString's wrapper around `always_inline` for various
  compilers as well, we can remove that as well.
Pull Request resolved: https://github.com/facebook/folly/pull/1079

Reviewed By: yfeldblum

Differential Revision: D14605330

Pulled By: Orvid

fbshipit-source-id: ec5529d8913fcec0a7eb03bce006d8fec71d525b

Round up microseconds to nearest millisecond value in the default TimeoutManager::scheduleTimeoutHighRes implementation

Summary:
Round up microseconds to nearest millisecond value in the default TimeoutManager::scheduleTimeoutHighRes implementation

(Note: this ignores all push blocking failures!)

Reviewed By: yfeldblum

Differential Revision: D14702027

fbshipit-source-id: b0c710c25c1d9b92ebf28e490507eb3dc3f4db31

Summary:
- We have several function objects that define constexpr call operators
  for `operator<`, `operator<=`, etc. These were needed prior to
  C++14 in order for them to be `constexpr`, as vendor implementations did not
  mark them `constexpr`.
- Since Folly requires C++14, callers who are relying on these should
  migrate to `std::less<T>`, and other function objects in the standard
  library, which are now marked constexpr.
Pull Request resolved: https://github.com/facebook/folly/pull/1020

Reviewed By: Orvid

Differential Revision: D14612068

Pulled By: yfeldblum

fbshipit-source-id: 378e148e6fd8e98cfba529c1e1c1a4d8f71dc8a7

Summary:
- Add deduction guide for `fbvector` which is only available if the
  feature test macro for deduction guides is available or if we are on
  MSVC.
Pull Request resolved: https://github.com/facebook/folly/pull/1090

Reviewed By: nbronson

Differential Revision: D14663586

Pulled By: yfeldblum

fbshipit-source-id: b3db8fc6ee3b13b84bb6a4a49d2a1801dc80fd4a

Reviewed By: yfeldblum, philippv, luciang

Differential Revision: D14713196

fbshipit-source-id: 327f2beb064e61e323edfaf9837bc39275bb8d14

Reviewed By: yfeldblum, larabear

Differential Revision: D14692263

fbshipit-source-id: fbdab61363ea83667832dbc56a883d069a1bd597

Summary:
This mirrors what we use when building thrift.
Without this, boost somehow picks a mix of static and shared
libs, but the static linkage doesn't know how to find the libdir
and thus the link fails.

This bubbles up when building folly's tests, which also require
linking with glog.

Reviewed By: yfeldblum

Differential Revision: D14700315

fbshipit-source-id: a331fdb493e7af62b42833b90bd20367778642ea

Summary:
The type is `HANDLE` but is being passed to something that
wants an `int` for a socket/file descriptor, so let's
explicitly translate this into a socket descriptor.

Reviewed By: yfeldblum

Differential Revision: D14680671

fbshipit-source-id: c7b3f6058ca486dbda01b069ec5d67cc2b3ea478

Summary:
this adds the include and library dirs for generated thrift targets;
these are important when those dependencies are not installed into a default
prefix.

Reviewed By: strager

Differential Revision: D14683957

fbshipit-source-id: ed47ffac5c8732810afe77e6947584b7a2f05155

Summary:
When finding a package via its config, we need to
add its include dirs to our list.  Previously we were squeaking
by for this because libevent was installed in either the default
include path or in the same installation prefix as folly.

In the getdeps build environment we have libevent in its own
installation prefix.

The `LibeventConfig.cmake` file from libevent `release-2.1.8-stable` exports
the include dirs via the `LIBEVENT_INCLUDE_DIRS` variable, which is slightly
different from that used by the `folly/public_tld/CMake/FindLibEvent.cmake`
file.

In a later diff I plan to standardize and move the libevent
logic to the common cmake dir.  For now, this unblocks my build.

Reviewed By: strager

Differential Revision: D14680677

fbshipit-source-id: 9f757c84fd145d052925803348008dc2c1abf263

Summary:
changes needed to add pushmi to xplat which is needed to make folly::Executor depend on pushmi.

split from - D12912583

MSVC 15.6.7 (required to keep cuda working) issues:
- __VA_ARGS__ results in a single token on MSVC and not on gcc or clang. I changed the macros to expand the single token so that it is parsed as multiuple tokens again
- some template usage must be placed inside `decltype()` to work with MSVC
- a nested set of macros using __VA_ARGS__ only worked on MSVC and clang when nested twice, but not when nested three times. changed the macros to use explicit parameters.
- gave up on pushmi invoke/invoke_result_t, now uses folly:Invoke instead.
- gave up on property_insert_t, removed usage that was needed for ExecutorTest
- switched many uses of make_receiver/make_sender to full bespoke receiver/sender implementations.
- disabled deduction guides on windows
- disabled apply on windows
- added additional disambiguity for function overloads that MSVC complained were redefinitions (only differed in SFINAE) also reduced to one `operator|` for this reason
- restructured `__property_category_t` and `__properties_t` to reduce MSVC ICE and other issues.
- MSVC did not like `property_set_element<POut, property_category_t<PIn>>` changed to `property_set_element<POut, PCategory>`
- MSVC complained about implicitly deleted destructors for `property_set_insert` explicitly added them..
- MSVC does not like `)::value` sequence added `bool_v`.
- replaced auto with explicit return types in some places.
- added the missing `remove_cvref_t`

In other news:
- added tags.h to minimize Executor dependencies on pushmi
- add `property_set_traits_disable_v` to allow EventBase to disable SequencedExecutor traits specialization
- add support for building without exceptions to the customization points

Reviewed By: ericniebler

Differential Revision: D14686496

fbshipit-source-id: c3f195783fd9a5f77b997498c44d4eebef1afe57

Summary: This diff adds the generator and recursive_generator classes from the cppcoro library to folly.

Reviewed By: lewissbaker

Differential Revision: D13834297

fbshipit-source-id: d27d11c39a35749c168a7c8e53c2819c36083467

Summary:
[Folly] Fix `folly/gen/test/ParallelMapTest.cpp` under MSVC, which does not appear automatically to deduce `{"str"}` as `std::initializer_list<char const*>`.

Breakage in {D14625210}.

Reviewed By: luciang

Differential Revision: D14663535

fbshipit-source-id: 092786236c6589790f234741e52b3fc045bd2b0e

Summary: This allows using blockingWait() with folly::SemiFuture.

Reviewed By: andriigrynenko

Differential Revision: D14658875

fbshipit-source-id: a99505bee3a9947d5fe89760ab495fce5679a0a1

Summary:
- For each F14 container, implement `erase_if(F14Container&, Predicate)` similar to C++20 `erase_if(std::unordered_map&, Predicate)`.
- The semantics of `erase_if` are that it erases all elements in the container which satisfy the given predicate.
Pull Request resolved: https://github.com/facebook/folly/pull/1069

Reviewed By: nbronson

Differential Revision: D14588030

Pulled By: yfeldblum

fbshipit-source-id: 87098804b993e9fb742f3a8feed43453aa99c885

Summary:
When running shell_building, the tree gets littered with __pycache__ files,
hence ignore them.

Reviewed By: wez

Differential Revision: D14664303

fbshipit-source-id: d41837cdfda1ae93c2d9330f00284128b3f7f7d0

Summary:
Extended `folly::coro::Task` to support an lvalue-reference value type.

A `Task<T&>` stores the value internally in a `folly::Try<std::reference_wrapper<T>>` as `folly::Try` does not support reference value types. This means that when you use `co_await task.co_awaitTry()` on a `Task<T&>` that you get back a `folly::Try<std::reference_wrapper<T>>` instead of a `folly::Try<T&>`.

Also added support for using `.co_awaitTry()` on `Task<T>`.
Previously the `.co_awaitTry()` method was only supported on the `TaskWithExecutor<T>` type.

Reviewed By: andriigrynenko

Differential Revision: D14657997

fbshipit-source-id: a168991b5a9c278dcc2387a6ff4fba9e47ccac0d

Summary:
Fix for the HHWheelTimer broken Windows build

(Note: this ignores all push blocking failures!)

Reviewed By: yfeldblum

Differential Revision: D14642461

fbshipit-source-id: 07292429b1e27eafeb144ab529940aee86dcca6d

Summary: As title.

Reviewed By: yfeldblum

Differential Revision: D14638826

fbshipit-source-id: 1904a1e416f299c2cafc147a3eb15dad325ae240

Summary:
As a step in the plan to migrate LogDevice to using fbcode_builder as
the primary build method, allow LogDevice to build without submodules.
In place of the self compiled modules, the CMake scripts will look in
the system (or provided prefix locations) and use precompiled modules
there. Users can then use fbcode_builder to ensure those required
modules are built and available.

* Use new 'folly_test_util' library rather than referencing sources
directly
Pull Request resolved: https://github.com/facebookincubator/LogDevice/pull/71

Reviewed By: AhmedSoliman

Differential Revision: D14578119

Pulled By: calebmarchent

fbshipit-source-id: 36400d41d3f1906919706d20d0fb53195fec2e63

Summary:
The alloc_hook is invoked on the malloc path. Therefore we should not
allocate on this path.

Reviewed By: yfeldblum

Differential Revision: D14605677

fbshipit-source-id: f95b9ff3e14f65781045d26ce59ec008c113ca81

Summary:
Back out D14608368 "HHWheelTimerBase: use different DEFAULT_TICK_INTERVAL values for milliseconds and microseconds".

The change being backed out breaks the MSVC build; backing it out should restore the MSVC build.

Fixes #1087.

Differential Revision: D14638652

fbshipit-source-id: b06b2934771adeff7a49c54b33da84a5bc973e66

Summary: removed constraints that are no longer valid.

Reviewed By: ericniebler

Differential Revision: D14606943

fbshipit-source-id: bf7acb88e3b6202caaa3e1333d88e5c516eb18e3

Summary:
This switches the output queue from `Output` to `Expected<Output, std::exception_wrapper>`, allowing exceptions to be produced by the predicate. Prior to this change, any exceptions would FATAL, taking down the whole process.

Benchmarks appear unaffected. Memory use will be very similar: Small objects are already padded out to a cache line, so the increase in size will often be zero.

Reviewed By: luciang

Differential Revision: D14625210

fbshipit-source-id: 9bfa1197b7d2285bbc7e42e829beeb3525b3bd44

Summary: Adding note and disabled test for now, will come back to fixing or killing this later.

Reviewed By: yfeldblum

Differential Revision: D14625209

fbshipit-source-id: 6e4f523c02e28fa6080da16485cba68ee78ffc80

Differential Revision:
D13966702

Original commit changeset: 415622dc347d

fbshipit-source-id: 11ff9cac08174cfaefe20e7e4c5e08dc005aaa39

Summary:
This causes problems with the cmake build because boost
triggers this warning, and we're promoting this to an error.

It is possible to use `-isystem` to tell the compiler that the
the boost headers are system headers, but introducing that for
boost headers is a mess.

We can safely live without this warning in the open source build
as our buck based builds have this enabled correctly.

Reviewed By: yfeldblum

Differential Revision: D14631786

fbshipit-source-id: cf30d0921ce592f410c2ad4bfddba1bddef01ed7

Summary: HHWheelTimerBase: use different DEFAULT_TICK_INTERVAL values for milliseconds and microseconds

Reviewed By: djwatson

Differential Revision: D14608368

fbshipit-source-id: 81ca30dead56e0ec954fce05c9f920e15dc20405

Summary:
- Clang 8 introduces a new compiler option which is turned on by
  default: `-Wdefaulted-function-deleted`.
- This flags some code which has special member functions which we
  declare as defaulted, but are implicitly deleted. As such, it is a bit
  misleading to mark them as defaulted. So, mark them as deleted. We
  could also remove them and they would be implicitly deleted, but then
  the internal linter would not like that we define a user defined type
  but are not explicit about deleting or defaulting all special member
  functions.

Note:
- This fixes some Clang 8 compilation issues, but
  https://github.com/facebook/folly/issues/1081 contains details about the
  remaining issues.
Pull Request resolved: https://github.com/facebook/folly/pull/1082

Reviewed By: Orvid

Differential Revision: D14613574

Pulled By: yfeldblum

fbshipit-source-id: 8011b3bc456bf92bbaf374c045fffb130e26d38b

Summary: This is a largely automated codemod that shifts `folly::AsyncServerSocket::AcceptCallback::connectionAccepted` to taking a `NetworkSocket` rather than a file descriptor. This needs to be done as a single atomic change to avoid breaking things.

Reviewed By: yfeldblum

Differential Revision: D13966702

fbshipit-source-id: 415622dc347de53368c404dfbe9a2deae5b75e18

Summary:
- Replace a check for deduction guide support to use a feature test macro
  for deduction guides rather than a check using `__cplusplus` directive.
- The existing check using the `__cplusplus` directive is not correct
  for GCC 5.1. With GCC 5.1, `__cplusplus > 201402L` will be true, but the check
  for `#if __cpp_deduction_guides >= 201703` will be false. So, it is
  not valid to just rely on the `__cplusplus` directive to infer
  deduction guide support.
- We extend the check to use the feature test macro except in the case
  of MSVC, which we infer the feature is supported. MSVC does not define
  feature test macros, despite having implemented the feature.
Pull Request resolved: https://github.com/facebook/folly/pull/1065

Reviewed By: aary

Differential Revision: D14518809

Pulled By: yfeldblum

fbshipit-source-id: a976ae527ef986ae6d3fc52c316af9bf8e209767

Summary:
[Folly] Cut `FOLLY_CACHE_LINE_SIZE` macro, replacing uses with `folly::hardware_destructive_interference_size`.

As one oddity, `FOLLY_CACHE_LINE_SIZE` had value 64 while `folly::hardware_destructive_interference_size` has value 128, so some types may get larger.

Reviewed By: aary

Differential Revision: D14574695

fbshipit-source-id: 7c5b9e313c5dcdecfec3cc47ec7bd55d08ae762c

Summary:
Add combined critical sections to DistributedMutex.  The implementation uses
the framework within DistributedMutex as the point of reference for contention
and resolves contention by either combining the lock requests of peers or
migrating the lock based on usage and internal state.  This boosts the
performance of DistributedMutex more than before - up to 4x relative to the
old benchmark on dual socket Broadwell and up to 5x on single socket Skylake
machines.  The win might be bigger when the cost of mutex migration is higher,
eg.  when the data being protected is wider than a single L1 cache line.
Small critical sections when used in combinable mode, can now go more than 10x
faster than the small locks, about 6x faster than std::mutex, up to 2-3x
faster than the implementations of flat combining we benchmarked against and
about as fast as a CAS instruction/loop (faster on some NUMA-less and more
parallel architectures like Skylake).  This also allows flat combining to be
used in situations where fine-grained locking would be beneficial with
virtually no overhead, DistributedMutex retains the original size of 8 bytes.
DistributedMutex resolves contention through flat combining up to a constant
factor of 2 contention chains to prevent issues with fairness and latency
outliers.  So we retain the fairness benefits of the original implementation
with no noticeable regression when switching between the lock methods.

The implementation of combined critical sections here is different from the
original flat combining paper.  This uses the same stack based LIFO contention
chains from DistributedMutex to allow the leader to resolve lock requests from
peers.  Combine records are located on the stack along with the wait-node as an
InlineFunctionRef instance to avoid memory allocation overhead or expensive
copying.  Using InlineFunctionRef also means that function calls are resolved
without having to go through the double lookup of a vtable based implementation.
InlineFunctionRef can flatten the virtual table and callable object in-situ
so we have just one indirection.  Additionally, we use preemption as a signal
to speed up lock requests in the case where latency of acquisition would have
otherwise gone beyond our control.  As a side-bonus, this also results in much
simpler code.

The API looks like the following
```
auto integer = std::uint64_t{};
auto mutex = folly::DistributedMutex{};

// ...

mutex.lock_combine([&]() {
  foo();
  integer++;
});
```

This adds three new methods for symmetry with the old lock functions
- folly::invoke_result_t<const Func&> lock_combine(Func) noexcept;
- folly::Optional<> try_lock_combine_for(duration, Func) noexcept;
- folly::Optional<> try_lock_combine_until(time_point, Func) noexcept;

Benchmarks on Broadwell
```
std_mutex_simple(1thread)                                  617.28ns    1.62M
google_spin_simple(1thread)                      101.97%   605.33ns    1.65M
folly_microspin_simple(1thread)                   99.40%   621.01ns    1.61M
folly_picospin_simple(1thread)                   100.15%   616.36ns    1.62M
folly_microlock_simple(1thread)                   98.86%   624.37ns    1.60M
folly_sharedmutex_simple(1thread)                 86.14%   716.59ns    1.40M
folly_distributedmutex_simple(1thread)            97.95%   630.21ns    1.59M
folly_distributedmutex_flatcombining_simple(1th   98.04%   629.60ns    1.59M
folly_flatcombining_no_caching_simple(1thread)    89.85%   687.01ns    1.46M
folly_flatcombining_caching_simple(1thread)       78.36%   787.75ns    1.27M
atomics_fetch_add(1thread)                        97.88%   630.67ns    1.59M
atomic_cas(1thread)                              102.31%   603.33ns    1.66M
----------------------------------------------------------------------------
std_mutex_simple(2thread)                                    1.14us  875.72K
google_spin_simple(2thread)                      125.08%   912.95ns    1.10M
folly_microspin_simple(2thread)                  116.03%   984.14ns    1.02M
folly_picospin_simple(2thread)                   117.35%   973.04ns    1.03M
folly_microlock_simple(2thread)                  102.54%     1.11us  897.95K
folly_sharedmutex_simple(2thread)                121.04%   943.42ns    1.06M
folly_distributedmutex_simple(2thread)           128.24%   890.48ns    1.12M
folly_distributedmutex_flatcombining_simple(2th  107.99%     1.06us  945.66K
folly_flatcombining_no_caching_simple(2thread)    83.40%     1.37us  730.33K
folly_flatcombining_caching_simple(2thread)       87.47%     1.31us  766.00K
atomics_fetch_add(2thread)                       115.71%   986.85ns    1.01M
atomic_cas(2thread)                              171.35%   666.42ns    1.50M
----------------------------------------------------------------------------
std_mutex_simple(4thread)                                    1.98us  504.43K
google_spin_simple(4thread)                      103.24%     1.92us  520.76K
folly_microspin_simple(4thread)                   92.05%     2.15us  464.33K
folly_picospin_simple(4thread)                    89.16%     2.22us  449.75K
folly_microlock_simple(4thread)                   66.62%     2.98us  336.06K
folly_sharedmutex_simple(4thread)                 82.61%     2.40us  416.69K
folly_distributedmutex_simple(4thread)           108.83%     1.82us  548.98K
folly_distributedmutex_flatcombining_simple(4th  145.24%     1.36us  732.63K
folly_flatcombining_no_caching_simple(4thread)    84.77%     2.34us  427.62K
folly_flatcombining_caching_simple(4thread)       91.01%     2.18us  459.09K
atomics_fetch_add(4thread)                       142.86%     1.39us  720.62K
atomic_cas(4thread)                              223.50%   887.02ns    1.13M
----------------------------------------------------------------------------
std_mutex_simple(8thread)                                    3.70us  270.40K
google_spin_simple(8thread)                      110.24%     3.35us  298.09K
folly_microspin_simple(8thread)                   81.59%     4.53us  220.63K
folly_picospin_simple(8thread)                    57.61%     6.42us  155.77K
folly_microlock_simple(8thread)                   54.18%     6.83us  146.49K
folly_sharedmutex_simple(8thread)                 55.44%     6.67us  149.92K
folly_distributedmutex_simple(8thread)           109.86%     3.37us  297.05K
folly_distributedmutex_flatcombining_simple(8th  225.14%     1.64us  608.76K
folly_flatcombining_no_caching_simple(8thread)    96.25%     3.84us  260.26K
folly_flatcombining_caching_simple(8thread)      108.13%     3.42us  292.39K
atomics_fetch_add(8thread)                       255.40%     1.45us  690.60K
atomic_cas(8thread)                              183.68%     2.01us  496.66K
----------------------------------------------------------------------------
std_mutex_simple(16thread)                                   8.70us  114.89K
google_spin_simple(16thread)                     124.47%     6.99us  143.01K
folly_microspin_simple(16thread)                  86.46%    10.07us   99.34K
folly_picospin_simple(16thread)                   40.76%    21.36us   46.83K
folly_microlock_simple(16thread)                  54.78%    15.89us   62.94K
folly_sharedmutex_simple(16thread)                58.14%    14.97us   66.80K
folly_distributedmutex_simple(16thread)          124.53%     6.99us  143.08K
folly_distributedmutex_flatcombining_simple(16t  324.08%     2.69us  372.34K
folly_flatcombining_no_caching_simple(16thread)  134.73%     6.46us  154.79K
folly_flatcombining_caching_simple(16thread)     188.24%     4.62us  216.28K
atomics_fetch_add(16thread)                      340.07%     2.56us  390.72K
atomic_cas(16thread)                             220.15%     3.95us  252.93K
----------------------------------------------------------------------------
std_mutex_simple(32thread)                                  25.62us   39.03K
google_spin_simple(32thread)                     105.21%    24.35us   41.07K
folly_microspin_simple(32thread)                  79.64%    32.17us   31.08K
folly_picospin_simple(32thread)                   19.61%   130.67us    7.65K
folly_microlock_simple(32thread)                  42.97%    59.62us   16.77K
folly_sharedmutex_simple(32thread)                52.41%    48.88us   20.46K
folly_distributedmutex_simple(32thread)          144.48%    17.73us   56.39K
folly_distributedmutex_flatcombining_simple(32t  461.73%     5.55us  180.22K
folly_flatcombining_no_caching_simple(32thread)  207.55%    12.34us   81.01K
folly_flatcombining_caching_simple(32thread)     237.34%    10.80us   92.64K
atomics_fetch_add(32thread)                      561.68%     4.56us  219.23K
atomic_cas(32thread)                             484.13%     5.29us  188.96K
----------------------------------------------------------------------------
std_mutex_simple(64thread)                                  31.26us   31.99K
google_spin_simple(64thread)                      99.95%    31.28us   31.97K
folly_microspin_simple(64thread)                  83.63%    37.38us   26.75K
folly_picospin_simple(64thread)                   20.88%   149.68us    6.68K
folly_microlock_simple(64thread)                  45.46%    68.77us   14.54K
folly_sharedmutex_simple(64thread)                52.65%    59.38us   16.84K
folly_distributedmutex_simple(64thread)          154.90%    20.18us   49.55K
folly_distributedmutex_flatcombining_simple(64t  475.05%     6.58us  151.96K
folly_flatcombining_no_caching_simple(64thread)  195.63%    15.98us   62.58K
folly_flatcombining_caching_simple(64thread)     199.29%    15.69us   63.75K
atomics_fetch_add(64thread)                      580.23%     5.39us  185.61K
atomic_cas(64thread)                             510.76%     6.12us  163.39K
----------------------------------------------------------------------------
std_mutex_simple(128thread)                                 70.53us   14.18K
google_spin_simple(128thread)                     99.20%    71.09us   14.07K
folly_microspin_simple(128thread)                 88.73%    79.49us   12.58K
folly_picospin_simple(128thread)                  22.24%   317.06us    3.15K
folly_microlock_simple(128thread)                 50.17%   140.57us    7.11K
folly_sharedmutex_simple(128thread)               59.53%   118.47us    8.44K
folly_distributedmutex_simple(128thread)         172.74%    40.83us   24.49K
folly_distributedmutex_flatcombining_simple(128  538.22%    13.10us   76.31K
folly_flatcombining_no_caching_simple(128thread  165.11%    42.72us   23.41K
folly_flatcombining_caching_simple(128thread)    161.46%    43.68us   22.89K
atomics_fetch_add(128thread)                     606.51%    11.63us   85.99K
atomic_cas(128thread)                            578.52%    12.19us   82.03K
```

Reviewed By: djwatson

Differential Revision: D13799447

fbshipit-source-id: 923cc35e5060ef79b349690821d8545459248347