sync: new internal semaphore based on intrusive lists

[hawkw]

Motivation

Many of Tokio's synchronization primitives (RwLock, Mutex,
Semaphore, and the bounded MPSC channel) are based on the internal
semaphore implementation, called semaphore_ll. This semaphore type
provides a lower-level internal API for the semaphore implementation
than the public Semaphore type, and supports "batch" operations, where
waiters may acquire more than one permit at a time, and batches of
permits may be released back to the semaphore.

Currently, semaphore_ll uses an atomic singly-linked list for the
waiter queue. The linked list implementation is specific to the
semaphore. This implementation therefore requires a heap allocation for
every waiter in the queue. These allocations are owned by the semaphore,
rather than by the task awaiting permits from the semaphore. Critically,
they are only deallocated when permits are released back to the
semaphore, at which point it dequeues as many waiters from the front of
the queue as can be satisfied with the released permits. If a task
attempts to acquire permits from the semaphore and is cancelled (such as
by timing out), their waiter nodes remain in the list until they are
dequeued while releasing permits. In cases where large numbers of tasks
are cancelled while waiting for permits, this results in extremely high
memory use for the semaphore (see #2237).

Solution

@Matthias247 has proposed that Tokio adopt the approach used in his
futures-intrusive crate: using an intrusive linked list to store the
wakers of tasks waiting on a synchronization primitive. In an intrusive
list, each list node is stored as part of the entry that node
represents, rather than in a heap allocation that owns the entry.
Because futures must be pinned in order to be polled, the necessary
invariant of such a list --- that entries may not move while in the list
--- may be upheld by making the waiter node !Unpin. In this approach,
the waiter node can be stored inline in the future, rather than
requiring separate heap allocation, and cancelled futures may remove
their nodes from the list.

This branch adds a new semaphore implementation that uses the intrusive
list added to Tokio in #2210. The implementation is essentially a hybrid
of the old semaphore_ll and the semaphore used in futures-intrusive:
while a Mutex around the wait list is necessary, since the intrusive
list is not thread-safe, the permit state is stored outside of the mutex
and updated atomically.

The mutex is acquired only when accessing the wait list — if a task
can acquire sufficient permits without waiting, it does not need to
acquire the lock. When releasing permits, we iterate over the wait
list from the end of the queue until we run out of permits to release,
and split off all the nodes that received enough permits to wake up
into a separate list. Then, we can drain the new list and notify those
wakers after releasing the lock. Because the split operation only
modifies the pointers on the head node of the split-off list and the
new tail node of the old list, it is O(1) and does not require an
allocation to return a variable length number of waiters to notify.

Because of the intrusive list invariants, the API provided by the new
batch_semaphore is somewhat different than that of semaphore_ll. In
particular, the Permit type has been removed. This type was primarily
intended allow the reuse of a wait list node allocated on the heap.
Since the intrusive list means we can avoid heap-allocating waiters,
this is no longer necessary. Instead, acquiring permits is done by
polling an Acquire future returned by the Semaphore type. The use of
a future here ensures that the waiter node is always pinned while
waiting to acquire permits, and that a reference to the semaphore is
available to remove the waiter if the future is cancelled.
Unfortunately, the current implementation of the bounded MPSC requires a
poll_acquire operation, and has methods that call it while outside of
a pinned context. Therefore, I've left the old semaphore_ll
implementation in place to be used by the bounded MPSC, and updated the
Mutex, RwLock, and Semaphore APIs to use the new implementation.
Hopefully, a subsequent change can update the bounded MPSC to use the
new semaphore as well.

Signed-off-by: Eliza Weisman eliza@buoyant.io

[hawkw]

Looks great. The only remaining issue that I see is the assert! max size set to u16::MAX.

Whoops, I missed that — should be all good now!

[cramertj]

I'm so happy to see people taking advantage of this property of pinning, which I thought was super cool. Thanks @Matthias247 for pushing on this both in your PRs to futures-rs and your work on futures-intrusive, and @hawkw for the implementation here!

[bothra90]

@Matthias247 : Is there a reason there's no poll-based API for tokio::sync::Semaphore? I am trying to use this in the Libra project inside a custom Stream implementation, and it would be really ergonomic to have an API like poll_acquire.

[carllerche]

@bothra90 The poll based APIs forced internal allocation. By using async / await, we can avoid that allocation. It should be possible to write a shim around the new Semaphore that is similar.