Introduce tokio-sync crate containing synchronization primitives.

[carllerche]

Introduce a tokio-sync crate containing useful synchronization primitives for programs written using Tokio.

The initial release contains:

• An mpsc channel
• A oneshot channel
• A semaphore implementation
• An AtomicTask primitive.

The oneshot and mpsc channels are new implementations providing improved performance characteristics. In some benchmarks, the new mpsc channel shows up to 7x improvement over the version provided by the futures crate. Unfortunately, the oneshot implementation only provides a slight performance improvement as it is mostly limited by the futures 0.1 task system. Once updated to the std version of Future (currently nightly only), much greater performance improvements should be achievable by oneshot.

Additionally, he implementations provided here are checked using Loom, which provides greater confidence of correctness.

[hawkw]

I've not finished reviewing the whole branch, but here are some minor nits and other non-blocking feedback on what I've reviewed to this point.

[arthurprs]

Shouldn't this kind of thing be futures-sync instead?

[carllerche]

@arthurprs given that it will be maintained by the Tokio team, it makes more sense to have it under the Tokio project IMO.

[ghost]

A few questions:

• What's the reason for exporting AtomicTask, i.e. when should one use it over futures::task::AtomicTask?

• Any reason why the API for acquiring permits in semaphore is the way it is? Why not have Semaphore::acquire(&self) -> Acquire<'_>, where Acquire is a future that returns a Permit on success, and dropping Permit releases it?

• Would it be better for Sender::poll_cancel() to be named Sender::poll_close()? One of my pet peeves with channels in general is that there are so many words that mean the same thing: close, disconnect, cancel (also see here). :)

[carllerche]

@stjepang

What's the reason for exporting AtomicTask, i.e. when should one use it over futures::task::AtomicTask?

It makes me feel more comfortable maintaining this infrastructure piece as all of Tokio relies on it. It has been updated to be checked w/ loom. There have been buggy changes merged into the AtomicTask in the futures crate in the past.

Any reason why the API for acquiring permits in semaphore is the way it is? Why not have Semaphore::acquire(&self) -> Acquire<'_>, where Acquire is a future that returns a Permit on success, and dropping Permit releases it?

There could be value in providing an API like that, but it would incur additional run-time cost. The proposed API has little run-time cost and is intended to be used as part of other data structures (like mpsc and blocking in tokio-threadpool. If, at some point, we introduce a Semaphore with the API you propose, we can rename this impl to RawSemaphore or something like that. Thoughts?

Would it be better for Sender::poll_cancel() to be named Sender::poll_close()?

I think that would be a good change. I will apply to the PR.

[ghost]

It makes me feel more comfortable maintaining this infrastructure piece as all of Tokio relies on it. It has been updated to be checked w/ loom. There have been buggy changes merged into the AtomicTask in the futures crate in the past.

Fair enough, that makes sense. It'd be good to eventually move our changes and loom-verified stuff back into futures, but it's no rush.

If, at some point, we introduce a Semaphore with the API you propose, we can rename this impl to RawSemaphore or something like that. Thoughts?

Fine by me. API design is hard. Let's keep the current semaphore and reevaluate it once we gain experience.

[ghost]

Very nice! I'm happy with the current state of the PR.

[seanmonstar]

🔥

[mauri870]

There's any plans to add mpmc channels to this library?

[steviezplayyard]

Sent from my T-Mobile 4G LTE Device

…

-------- Ohcriginal message -------- From: Mauri de Souza Nunes <notifications@github.com> Date: 1/24/19 5:54 AM (GMT-07:00) To: tokio-rs/tokio <tokio@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [tokio-rs/tokio] Introduce tokio-sync crate containing synchronization primitives. (#839) There's any plans to add mpmc channels to this library? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#839 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AoPIUcsyh_7svNaYfweD-HJ1uSUlow13ks5vGa0egaJpZM4Z4b5N>.

[bkchr]

Sorry for being that late, but what was the reason for this file and tx.rs, if both are empty and not used?

[carllerche]

Ah... just forgot to delete them I guess.

[carllerche]

@mauri870 at some point probably. Just have to come up w/ a strategy that works.