Skip to content

embassy-sync: add ThreadModeRawMutex support for riscv32#5822

Open
cong-or wants to merge 1 commit intoembassy-rs:mainfrom
cong-or:riscv32-thread-mode-mutex
Open

embassy-sync: add ThreadModeRawMutex support for riscv32#5822
cong-or wants to merge 1 commit intoembassy-rs:mainfrom
cong-or:riscv32-thread-mode-mutex

Conversation

@cong-or
Copy link
Copy Markdown

@cong-or cong-or commented Apr 8, 2026

Fix ThreadModeRawMutex behavior on RISC-V (#5133)

ThreadModeRawMutex only works on cortex_m right now, so it can’t be used on riscv32 targets.
The RISC-V executor is thread-only for now, so in_thread_mode() just returns true.

If we add an interrupt executor for RISC-V in the future, this will need proper tracking—but that’s a separate PR.

Testing

  • Builds cleanly on riscv32imac-unknown-none-elf
  • All host tests pass

Comment on lines +149 to +151
#[cfg(riscv32)]
// No interrupt executor on RISC-V yet, so always in thread mode.
return true;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's false, esp-hal/esp-rtos provides an interrupt executor for risc-v chips.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bugadani Would an AtomicBool that the interrupt executor sets on entry/exit work? Or does esp-hal already have a mechanism for tracking interrupt context that this should hook into?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no standard interrupt controller on RISC-V chips, and embassy-sync shouldn't rely on anything ESP32-specific. I'm not aware of an implementation-independent way to check if code is running in a thread context

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't an AtomicBool set/cleared by the executor itself be implementation-independent? It doesn't need to know anything about the interrupt controller — just that the executor entered/exited interrupt context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants