Semaphores is used to share the resources (a Section of code/task/Process/Thread with another) to use the code segments in a cooperative way. It is not necessary that the system is using a disciplined scheduler to schedule tasks/processes, it may be a global variable which can be polled & wait for status/count by a section of code, until other section it using a particular section of code & doesn't change its status/affect count after he is done. In OS related terminology such variables are named as Semaphores. For Example: Suppose we have a IR emitter in our system, if any task or multiple sources are allowed to send decoded data to IR ports/it may be done by some other controller on board which may be communicating through SPI/I2C bus. Problem 1: we are sending IR Signals, if they are mixed with other data/signal them whole packet will be of no meaning, they are generally commands to control an IR device (which understands exact pattern), will not understand that pattern. So, if two events from different task tries to send data or IR controller will destroy the data (IR command). Problem 2: If on board controller taking processed IR commands on SPI bus, then, only one device can be communicated over it through MOSI, as at a time CS can have only one value to select multiple devices on SPI bus at a time. So, a cheap solution without increasing hardware to send multiple commands, we can make some arrangement to queue up the events & data in some buffer (it is up to implementation/as per requirement, what wold be processing sequence of commands to execute, either LIFO or FIFO can be used) & send it to IR controller one by one. And that arrangement may be a semaphore. in which all tasks who want to send IR signal on some events (like some buttons for IR commands sending function associated are pressed by user on iPad & is came through TCP, which invoked the tasks), we can not restrict user to not send multiple commands in short time or wait for first command to respond, but, i can have the semaphore lock, which will lock a critical section (IR sending over SPI bus in his case) & won't release the lock until it is not sent successfully & other queued up events & data will wait for this lock to get released. Here one section (a task who received event) is locking the resource & other is releasing it. Their is one more similar thing called Mutex, which is similar to semaphore, but, the difference is it can not be shared between different processes, semaphore can be shared between processes apart from local threads of a process. Mutex can only be unlocked by the task/process/thread who locked it. But if you forget to unlock them on correct places, they may make your code unresponsive, as in such cases resource remains locked for ever.