Semaphore and Spinlock

Semaphore and Spinlock

[Abhishek Bist]

[ 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.

Semaphore and Spinlock

[Ruben Safir]

On 04/27/2015 09:18 AM, Abhishek Bist wrote:
> [ 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.
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 
> 


That is a good question.  In fact, I've been studying semaphores,
spinlocks and Mutexes now for 3 weeks and it still confuses me.  Our
school is working from a text called Operating Systems Concepts 9th
Edition.  It seems to avoid defining things

It should say

Definition:
Semephore
Mutex:
Spinlocks:

and then there is monitors

I have poured over a lot of sample code.  I can show you coding examples
for concurrence protection from race condition, and models for mutexes,
and even describe what a wait queue might look like, but in the end, I'm
still puzzled by this most basic of definition.  A lot of this is the
fault of the book.  They get lost in their own words, research and
thoughts and fail to deliver understand concepts to the student.

Forget operating systems.  Lets say I am writing a book about Bicycles
and the principles of Bicycle design.  And we are going to study wheels.
 It makes for very ineffective communication to spend 10 pages
describing that C=2piR and other facts about circle geometry, and the
mathematical calculation of force when applied to a spoke(or a rope)
under tension, et et et and forget to define that a Wheel on a bicycle
is a round hoop, usually covered on the outer rim by a rubber tire, that
makes contact to the road and allows for the bicycle to roll.

Semaphore and Spinlock

[Jeff Haran]

> -----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 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 spinlock.

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

Semaphore and Spinlock

[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
>
>

Semaphore and Spinlock

[Jeff Haran]

> -----Original Message-----
> From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
> bounces at kernelnewbies.org] On Behalf Of Ruben
> Sent: Monday, April 27, 2015 12:10 PM
> To: kernelnewbies at kernelnewbies.org
> Subject: Re: Semaphore and Spinlock
> 
> 
> 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.
> 

This text was in an introduction. I was simply commenting that the original text seemed to provide a reasonable analogy ("a bit like spinlocks") at the conceptual level.

One can always find differences via some anal retentive run off into the weeds of its implementation.

Jeff Haran

> 
> 
> 
> > 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
> >
> >
> 
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies