tweedegolf / async-heapless Goto Github PK

This is more of a feature request than a bug. You can reduce the amount of AtomicWaker operations by adding a fast-path:

        if let Some(message) = unsafe { self.0.take() } {
            return Poll::Ready(message);
        }
        self.0.waker.register(cx.waker());
        if let Some(message) = unsafe { self.0.take() } {
            Poll::Ready(message)
        } else {
            Poll::Pending
        }

There's no reason for the Release in the store above, and this can be changed to Relaxed, as there are no writes to the shared data occurring prior to the store operation. We know this because of core::ptr::read:

Reads the value from src without moving it. This leaves the memory in src unchanged.

This line writes to AtomicWaker:

There's potentially a memory ordering issue here that could lead to a missed wakeup. futures-0.3.8 memory ordering:

Calling register "acquires" all memory "released" by calls to wake before the call to register. Later calls to wake will wake the registered waker (on contention this wake might be triggered in register).

For concurrent calls to register (should be avoided) the ordering is only guaranteed for the winning call.

This does not work for your code. Your register could get reordered past your wake.

To make this truly correct, you need to make sure that has_message.load() in take does a release and that the subsequent has_message.store() in put does an acquire.

Since those are not valid memory orderings in for load and store, you need to use fences

You need a release fence between the call to AtomicWaker::register and has_message.load(), and you need an acquire fence between the call to has_message.store() and AtomicWaker::wake.

Or you could use SeqCst

It is claimed that put and take can be called concurrently. Both methods call UnsafeCell::get()

Ensure that the access is unique (no active references, mutable or not) when casting to &mut T

But put calls MaybeUninit::write() which casts it to &mut MaybeUninit<T>. You do not guarantee that the reference is unique, given that there could be a concurrent &MaybeUninit<T> in a concurrent call to take.