Binary Semaphore #53
Labels
No Label
API Change
Breaking API Change
bug
build
cosmetics
Documentation
duplicate
feature
help wanted
hotfix
invalid
question
Refactor
Tests
wontfix
No Milestone
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: fsfw/fsfw#53
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I am trying to find a way to integrate binary semaphores as a signalling mechanism. The basic minimal interface is equivalent to the MUtexIF, but if we use the same interface, we would need to rename it to SemaphoreIF, and call the function lock() und unlock().
I am also not sure that putting both in the same interface is a good idea because they are used for different purposes (mutual exclusion <-> synchronization) and a class should only do one thing. Most APIs use give/take, release/obtain, notify/wait instead of lock/unlock anyway.
For our specific mission code, I still need the capability so give or take a semaphore with an external handle and I need to access the semaphore handle directly(which is private for the mutex for example). There are also other issues I will address in a separate issue.
For Linux, there seems to be an API for semaphores:
http://openbook.rheinwerk-verlag.de/linux_unix_programmierung/Kap10-006.htm#RxxKap10006040003201F0281B2
For RTEMS, there is a semaphore manager:
https://docs.rtems.org/branches/master/c-user/semaphore_manager.html
And with C++11 on linux, one can also build a binary semaphore
with language features apparentely:
https://stackoverflow.com/questions/4792449/c0x-has-no-semaphores-how-to-synchronize-threads
What do you think?