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