To explain further about how counting semaphores are used, shown here is another analogy. Imagine a restaurant with a limited number of tables (in this case 4), and quite a few more customers then that. Each one of these customers are like independent tasks, and each of those tables represents a resource that a customer wants to take for some period of time. To avoid the disaster of having multiple customers trying to sit at a single table, the restaurant has a maitre d’. The maitre d’ is like a semaphore and it referees how the resources are taken and given back up. Because there are 4 tables, the program will initialize the semaphore to a count of 4. As each customer task wants a table, it will perform a Semaphore-pend() call, and each of those calls will decrement the semaphores count. While tables are available, the semaphore count is greater than 0, and the pend calls will simply fall though, allowing the tasks to keep executing. But once all the tables are full, the semaphore count is zero and any more tasks calling Semaphore_pend will block on that call. Once a customers task is done with the table, it performs a Semaphore_post, incrementing the semaphores count and allowing the next blocked task to run so that it can grab the resource for its own use. Note that, even with a multitude of tasks and 4 resources, all the arbitration can be done with a single counting semaphore. Also note how important it is that the semaphore operations are atomic, this means that the task cannot be interrupted while the semaphore is in the midst of getting posted or pended, so the operation stays safe and coherent.