Semaphore and Spinlock

[ruben@mrbrklyn.com (Ruben)]

On 04/27/2015 12:31 PM, Jeff Haran wrote:
>> -----Original Message-----
>> From: kernelnewbies-bounces+jharan=bytemobile.com at kernelnewbies.org
>> [mailto:kernelnewbies-
>> bounces+jharan=bytemobile.com at kernelnewbies.org] On Behalf Of
>> Abhishek Bist
>> Sent: Monday, April 27, 2015 6:19 AM
>> To: kernelnewbies at kernelnewbies.org
>> Subject: Semaphore and Spinlock
>>
>> [ Semaphores are a bit like spinlocks, except the holder of a semaphore is a
>> process, not a CPU. ] This is a very first line that is bein written on the
>> description of semaphore on kernel newbies.So what are the different
>> parameter that could justify this statement or the way it could be justified
>> and understood.
>>
>> It makes sense to me conceptually. Say you are running some kernel code on a

> multicore system and that code serializes access to some data structure via a spinlock.

>   If core A takes the spinlock, then core B comes along and tries to take it, core B will


No - that is completely confused.   A semaphore doesn't even imply a lock.
When a wait calls and the semaphore is less than zero, then the process 
that called
wait then is put on the wait queue and essentially blocks itself.

When a process signals a semaphore, it increments the semaphore and 
then, if the
value of the semaphore is <= 0 its goes and signals the wait queue for 
next waiting task
from the wait queue and puts in on the run queue for scheduling.




> spin until core A releases the spin lock, at which point core B will hold it. Conceptually, core B is prevented from doing anything else while core A holds the spinl
> Now say you are running some kernel code that is executed in the context of multiple processes and that code serializes access to some data structure via a semaphore. If process A takes the semaphore, then process B comes along and tries to take it, process B will block (the core B is running on will do a context switch to some other process) until process A releases the semaphore, at which point process B will hold it and once the scheduler on B's core allows process B will start running again. Conceptually, process B is prevented from doing anything else while process A holds the semaphore. A mutex here would also apply.
>
> Semaphore is to process like spinlock is to core, at least in this case where the semaphore is being used for mutual exclusion.
>
> Jeff Haran
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>