Replace the workqueue executor entirely #85
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Implement a proc macro that allows a declaration like:
```rust
fn mythread(arg: usize, arg2: &'static Thing) { .. }
```
With this change, creation of threads, with arbitrary "Send" arguments
can be done without needing allocation. The macros reserves a static
area alongside the `k_thread` structure to use for handing the threads
over.
This creates a function `mythread` with the given args that returns a
ReadyThread. This has a `start()` method which will begin execution of
the thread. This results in a RunningThread, which has a join method
that can be used to wait for termination.
Signed-off-by: David Brown <[email protected]>
Move away from the `kobj_define` task declaration to use the new `#[zephyr::thread]` to define these. This allows for a more natural declaration where the thread just looks like an attribute added to a regular function declaration. This also eliminates the static Mutex, as the Mutex now has a constructor that avoids allocation (it is still put in an Arc, though). Signed-off-by: David Brown <[email protected]>
To help with debugging, try to give created Zephyr threads a readable name. Currently, this is based off of the name of the function used in the declaration of the thread. Signed-off-by: David Brown <[email protected]>
Remove the sample that depended on the old non-standard executor built around work queues, and use the zephyr-executor. Signed-off-by: David Brown <[email protected]>
Change this to be more general about the async executor used, instead of the zephyr-specific workq-based one. This doesn't change the sample itself, just the name. Signed-off-by: David Brown <[email protected]>
The work-queue-based executor was an attempt to implement a Rust executor that worked with Zephyr work queues. Although it was possible to make something that kind of worked, and did have the advantage of being able to use a few Zephyr primitives, it suffers from several problems: - It isn't very efficient, basically combining the overhead of async scheduling, triggered work, and the Zephyr thread scheduler. - It plays poorly with any other use of async. Since it is useful to be able to use external crates for async utilities, this normally just results in undefined-behavior. Now that we have another executor (built from Embassy), this code is also mostly unneeded. Signed-off-by: David Brown <[email protected]>
Convert away from the Zephyr-specific async to standard Rust async. This uses the Embassy crates for time and synchronization. All tasks are spawned within a single executor that runs in the main thread. Signed-off-by: David Brown <[email protected]>
Import the embassy crates, but not by path. Also, remove the specific time instance. Although and specific application will likely want to use a non-default tick rate, leaving at the 1us tick will allow the time to be used (with a slight performance cost) with any time base. Signed-off-by: David Brown <[email protected]>
The pin-weak provides a weak pointer that is compatible with `Pin<Arc>`. Unfortunately, these are not compatible with the Arc that we use from portable-atomic-utils. Provide a simplified implementation of this until the pin-weak is able to gain this functionality. Signed-off-by: David Brown <[email protected]>
The current benchmarks are failing with a stack overflow on 64-bit targets, so increase the size a bit. Signed-off-by: David Brown <[email protected]>
This only makes sense when alloc is enabled. Move the type into a module, and use it, all conditional on having alloc defined. Signed-off-by: David Brown <[email protected]>
Semaphores no longer use alloc in `new`. Remove the incorrect conditional based on allocation that remained. Signed-off-by: David Brown <[email protected]>
cfriedt
approved these changes
Apr 12, 2025
teburd
approved these changes
Apr 12, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Now that we have an async executor that runs on a regular thread, remove the previous work-queue based executor entirely. This incorporates improvements to the bench sample developed while making this change.