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

Semaphore::create_binary can't be used #16

Closed
bugadani opened this issue Oct 14, 2021 · 4 comments
Closed

Semaphore::create_binary can't be used #16

bugadani opened this issue Oct 14, 2021 · 4 comments

Comments

@bugadani
Copy link

Quoting the docs:

[...] binary semaphores created using xSemaphoreCreateBinary() are created in a state such that the the semaphore must first be 'given' before it can be 'taken'

The Semaphore API only allows locking, and then dropping the guard, which means there is no way to "give" a binary semaphore. This API also makes using Semaphores as synchronization tools unwieldy.

@niondir
Copy link
Member

niondir commented Jan 19, 2022

Good point. PR is welcome. Since I'm not maintaining any active code using this repo there is not much activity from my side, but any help is welcome.

@apullin
Copy link
Contributor

apullin commented Sep 26, 2022

One solution would be to directly implement give and take, per the FreeRTOS API, which does not hand back a SemaphoreGuard. lock, which does, can still exist, too. This would also be "familiar" for people familiar with FreeRTOS.

Even looking at the std::sync::Mutex, doing a directly unlock requires unstable features to call drop directly:
https://doc.rust-lang.org/src/std/sync/mutex.rs.html#337-339

If you really wanted completeness, some properly named version of new_binary like new_binary_ready could be implemented to just call the shim function to give it at the time of creation.

@agerasev
Copy link
Contributor

agerasev commented Jan 3, 2023

This issue seems to have been fixed in #46 in exactly this way:

One solution would be to directly implement give and take, per the FreeRTOS API, which does not hand back a SemaphoreGuard.

@schteve
Copy link
Collaborator

schteve commented Jan 3, 2023

Agree, will close. If anyone feels there's more to do we can re-open.

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

No branches or pull requests

5 participants