Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why does Tasklet require a Mutex? #54

Open
srobertjames opened this issue Sep 21, 2023 · 3 comments
Open

Why does Tasklet require a Mutex? #54

srobertjames opened this issue Sep 21, 2023 · 3 comments
Assignees
Labels

Comments

@srobertjames
Copy link

We're evaluating the freertos-c++ lib for possible usage. Can you explain why Tasklet involves a Mutex? That doesn't seem to be the typical usage pattern in the underlying FreeRTOS C implementation.

@michaelbecker
Copy link
Owner

It's to protect against race conditions that might occur if/when the Tasklet is deleted. You can see an example usage in
https://github.com/michaelbecker/freertos-addons/blob/master/Linux/Demo/Linux_g%2B%2B_tasklets/main.cpp

@srobertjames
Copy link
Author

Thanks. By "deleted" do you mean "deleted from RAM via delete operator"? Or "deleted from FreeRTOS Task List"?

@michaelbecker
Copy link
Owner

Both. If you are using the C++ wrappers and you decide you want to permanently delete a Tasklet object, then you should be calling the delete operator, either directly or indirectly (like when a local object goes out of scope). Just make sure you include a call to CheckForSafeDelete() in your destructor to prevent any weird race conditions. In that code I've leveraging the semaphore/mutex again to guarantee FreeRTOS doesn't try to run your tasklet code after you've deleted it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants