This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS: How does Binary Semaphore works?

Tool/software: TI-RTOS

Hi there, Could someone explain me how does the binary semaphore works???

If semaphore is already posted and then one more semaphore is posted, would this mean now the binary semaphore is not available? as in count = 0? 

Regards,

Mitesh

  • Here are some different scenarios for a binary semaphore. Note: count == 0 means the semaphore is not available (i.e. if you call pend, you will block or return false if you specified a zero timeout). Count == 1 mean the semaphore is available

    Use Cases
    1. count == 0, call Semaphore_pend with a timeout, no one calls Semaphore_post: you block (and other things run) until the timeout expires and the return code is FALSE. Count is still 0.
    2. count == 0, call Semaphore_pend with a zero timeout: you return immediately with the return code is FALSE. Count is still 0.
    3. count == 0, call Semaphore_pend with a timeout, someone calls Semaphore_post before you expire: you block until the Semaphore_post call is made. If you are a higher priority, you start to run. If not, you are in the ready state. The return code is TRUE and count is still 0.
    4. count == 0, no one is calling Semaphore_pend, someone calls Semaphore_post: count goes to 1.
    5. count == 1, no one is calling Semaphore_pend, someone calls Semaphore_post: count stays at 1. (here a counting semaphore would go to 2).

    Binary semaphores are useful when you just want the action taken and you don't care how many times. My example is that I ask my teenage kids to take the trash out. I have to ask them multiple times (e.g. multiple Semaphore_posts). They eventually take the trash out once. It does not make sense to make them take it out N times in one night (but they might lose computer privileges for responding slowly:)).

    Todd

  • Ha ha ;) good example ;)
    Point 3) is that right? If the timeout is forever and the Semaphore_pend is waiting... and if someone posts a semaphore the waiting semaphore task will run if priority is high enough and the semaphore count = 0, which makes sense.. what if for some reason the pending task was not high priority the count = 0?? or would it be 1 in this case?

    I converted some of the semaphores in my designs to binary bcoz as you said it makes sense to use binary semaphore for tasks which needs running just ones! In my design I send some data out on UART at 100 Hz and post this semaphore whenever the data is ready.. but what I noticed was if for some reason the system was busy doing something else the semaphore count kept inc and when the system was free, it then sent same data multiple times..
  • Good question! Let's break 3 into two case

    3: count == 0, call Semaphore_pend with a timeout in Task A, Task B calls Semaphore_post before Task A's pend expires:

    a. Task A (task in pend and is blocked) has a higher priority than Task B (caller of post)
    When Task B calls post, the scheduler sees that Task A is blocked on the semaphore. Instead of incrementing the count, it leaves the count at 0. The scheduler also sees that Task A is higher priority, so it makes it the running task (and Task B be preempted).

    b. Task A (task in pend and is blocked) has the same or lower priority than Task B (caller of post)
    When Task B calls post, the scheduler sees that Task A is blocked on the semaphore. Instead of incrementing the count, it leaves the count at 0. The scheduler also sees that Task A is the same or lower priority, so it makes it the task "ready". So once Task B is blocked, Task A can run (assuming nothing else with higher priority is ready to run).

    Some RTOS vendors do handle case b different. For example, I believe with FreeRTOS, the count is not decremented. This allows Task B to call Semaphore_pend and get the semaphore.

    Since it is kinda related... TI-RTOS does supply two different behaviors for the semaphore pend queue (more than one task pending on a semaphore). The default way is FIFO. First task that calls Semaphore_pend on a semaphore that is not available will get it when a post occurs. The other way is by priority. Whomever is the highest priority will get the semaphore when it available via a post. Both have their use cases. You need to enable the priority support method in the .cfg file since it adds a little footprint. The kernel's API documentation for semaphore goes into more details.

    Todd
  • Thanks for your reply. Cheers.