I wanted to clarify something about semaphores and how they work. It’s often said that semaphores can let multiple threads access a resource at the same time, but only up to a certain limit.
However, in my understanding, on a single-core CPU, only one task can access a resource at a time.
For example, if we have three tasks that need to access a shared resource, only one task can access it at a time, and the others have to wait until the current task is finished. So, saying that semaphores allow multiple threads to access a resource simultaneously might not be accurate.
yes, a single core CPU will be execution only one instruction at a time, but the swithing between thread can happen at any point in the exectuion.
Using a counting semaphore with a count of three, says that only three threads can be in the part of their code that accesses that resource at a time, and others are blocked and prevented from getting there.
If you use a binary semaphore (or better a Mutex) then only one task will “own” that access and be able to be in the code that accesses it, thus you don’t need to worry about the possibility that some other task will get switched in and access that same resource in the middle of your operations.
Consider a scenario where three tasks with equal priority need to access shared resources simultaneously. If a counting semaphore is initialized with a count of 3, indicating that only three tasks can access the resources concurrently, which task will gain access first if all three tasks attempt to access the resources simultaneously?
Sorry, I don’t get it … Do you want to protect a resource (for instance a HW peripheral ) from being accessed concurrently ? Then use a mutex.
Counting semaphores have different purposes or use caes. I ‘d recommend this post discussing them.
I’ll try my best to explain what I want to understand.
Imagine we have five tasks: A, B, C, D, and E. I want to allow only three tasks – A, B, and C to access resource simultaneously using a counting semaphore. This ensures that only three tasks A, B and C can access the resource at time , D and E being restricted.
In the scenario where tasks A, B, and C all attempt to access the resource concurrently, which task will gain access first?
First, I will point out that a multi-shared resource (like our count of 3 example) is somewhat rare. Few resources allow 2 or 3 concurrent accesses but not unlimited are rare. It more occurs in the case that there are “N” resources guarded by the count, so FIRST a task passed by the counting semaphore, and then finds which of the resources is actually free, and then claims exclusive use of it. This means waiting tasks get notified if ANY of the resources are available, instead of having to pick one and then find they got into the slow line at checkout.
As far as granting access, the semaphore will grant based on priority, and within priority who got there first (you go in the line AFTER everyone with your priority).
Note, with a single processor, task A, B and C can’t ask at one time, as only one task runs at any given instant, and thus the do come “in order”, and ALL THREE will be granted the access as they arrive in turn.
Even on a multi-core processor, inside the arbitrartion system, the code for the semaphore enters a mutual exclusion zone during which only one processor, and one task on that processor, can be working, so you still have an order, even if it is decided somewhat arbitrary by who gets the mutual exclusion zone first.