Binary semaphores are really just counting semaphores with a maximum count of 1. They are most often used for synchronization. When a task needs to synchronize on an event, it will attempt to take a semaphore, blocking until the semaphore becomes available or until the specified timeout has elapsed. Another asynchronous part of the system (either a task or an ISR) will give a semaphore. Binary semaphores can be given more than once; there is no need for that piece of code to return them. In the following example, TaskA only gives a semaphore, while TaskB only takes a semaphore:

TaskB is set up to wait for a signal (semaphore) before proceeding with its duties: 

1. Initially, TaskB attempts to take the semaphore, but it wasn't available, so TaskB went to sleep. 
2. Sometime later, TaskA gives the signal.
3. TaskB is woken up (by the scheduler; this happens in the background) and now has the semaphore. It will go about the duties required of it until it is finished. Notice, however, that TaskB doesn't need to give back the binary semaphore. Instead, it simply waits for it again. 
4. TaskB is blocked again because the semaphore isn't available (just like the first time), so it goes to sleep until a semaphore is available.
5. The cycle repeats.

Next, we'll discuss a special type of semaphore with some additional properties that make it especially well suited for protecting items that can be accessed from different tasks – the mutex.