The async-on-embedded's discuss from ferrous-systems

3-mutex-example: Deadlock

I am porting the examples to the Blue Pill (STM32F103C8T6).

In example 3-mutex I only get the following output:

B: before lock
A: before write

The expected output:

B: before lock
A: before write
A: after releasing the lock
A: yield
B: 42
DONE

The Microcontroller is currently waiting for events with the following back trace:

#0  0x08004d5e in __wfe ()
#1  0x08001390 in cortex_m::asm::wfe ()
    at /home/mkroening/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-0.6.2/src/asm.rs:97
#2  0x08000b02 in <async_cortex_m::unsync::mutex::MutexGuard<T> as core::ops::drop::Drop>::drop (self=0x20004d24)
    at /home/mkroening/Development/rust-embedded/async-on-embedded/async-cortex-m/src/unsync/mutex.rs:97
#3  0x08000ad0 in core::ptr::drop_in_place ()
    at /home/mkroening/.rustup/toolchains/nightly-2020-04-06-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/ptr/mod.rs:177
#4  0x080012f2 in core::mem::drop (_x=...)
    at /home/mkroening/.rustup/toolchains/nightly-2020-04-06-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/mem/mod.rs:880
#5  0x080016de in _3_mutex::__cortex_m_rt_main::{{closure}} ()
    at examples/3-mutex.rs:47
#6  0x080006dc in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll (self=..., cx=0x20004f0c)
    at /home/mkroening/.rustup/toolchains/nightly-2020-04-06-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66
#7  0x08000634 in core::future::poll_with_context (f=..., cx=...)
    at /home/mkroening/.rustup/toolchains/nightly-2020-04-06-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84
#8  0x08001bc2 in async_cortex_m::executor::Node$LT$dyn$u20$core..future..future..Future$u2b$Output$u20$$u3d$$u20$$LP$$RP$$GT$::new::_$u7b$$u7b$closure$u7d$$u7d$::h309ac6bb8a264efb ()
    at /home/mkroening/Development/rust-embedded/async-on-embedded/async-cortex-m/src/executor.rs:162
#9  0x0800078e in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll (self=..., cx=0x20004f0c)
    at /home/mkroening/.rustup/toolchains/nightly-2020-04-06-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66
#10 0x08001ebe in async_cortex_m::executor::Executor::block_on (
    self=0x20000098 <async_cortex_m::executor::current::EXECUTOR>, f=...)
    at /home/mkroening/Development/rust-embedded/async-on-embedded/async-cortex-m/src/executor.rs:107
#11 0x08001586 in async_cortex_m::task::block_on (f=...)
    at /home/mkroening/Development/rust-embedded/async-on-embedded/async-cortex-m/src/task.rs:17
#12 0x08001972 in _3_mutex::__cortex_m_rt_main (
    X=0x20000000 <_3_mutex::__cortex_m_rt_main_trampoline::X>)
    at examples/3-mutex.rs:57
#13 0x08001912 in main () at examples/3-mutex.rs:38

The issue seems to be waiting for events after notifying any waker when dropping the MutexGuard:

async-on-embedded/async-cortex-m/src/unsync/mutex.rs

Lines 96 to 97 in 341fa1c

 self.0.wakers.notify_any(); 

 asm::wfe();

I think this behavior (introduced in a008306) is not intended, as in other synchronization primitives we signal events instead after notifying wakers:

async-on-embedded/async-cortex-m/src/task.rs

Lines 45 to 46 in 341fa1c

 cx.waker().wake_by_ref(); 

 asm::sev();

async-on-embedded/async-cortex-m/src/unsync/channel.rs

Lines 139 to 140 in 341fa1c

 self.send_wakers.notify_one(); 

 asm::sev();

async-on-embedded/async-cortex-m/src/unsync/channel.rs

Lines 164 to 165 in 341fa1c

 self.recv_wakers.notify_one(); 

 asm::sev();

I'll follow up with a PR.

What do you think?

Note that the corresponding example from the "async/await on embedded Rust" blog post does not suffer from this, as B explicitly yields after the drop, signaling events that way.

Suggestion use wfe

Hi,

I find your work really interresting so I check a bit the source file and I see that you put a TODO in executor.rs (line 110):

        // TODO try to sleep (WFI) here
        // just calling WFI here will result in missed notifications because
        // a `Waker` (called from an interrupt handler) may run just after
        // we exit the `for` loop but before WFI is called. Then the system
        // won't wake up until the *next* interrupt handler is triggered
        // (which could end up never running if the applications used only a
        // single interrupt)

After some search on the web I see that effectively WFI on cortex-m0 doesn't do any check before going in sleep mode, not like on cortex-m3 where it should work.

But it look like WFE does'nt have this problem and could be used.

I'm probably not seeing another problem but I wanted to try.

ferrous-systems / async-on-embedded Goto Github PK

async-on-embedded's Issues

3-mutex-example: Deadlock

Suggestion use wfe

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent