> -----Original Message----- > From: kernelnewbies-bounces@xxxxxxxxxxxxxxxxx [mailto:kernelnewbies- > bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Ruben > Sent: Monday, April 27, 2015 12:10 PM > To: kernelnewbies@xxxxxxxxxxxxxxxxx > Subject: Re: Semaphore and Spinlock > > > On 04/27/2015 12:31 PM, Jeff Haran wrote: > >> -----Original Message----- > >> From: kernelnewbies- > bounces+jharan=bytemobile.com@xxxxxxxxxxxxxxxxx > >> [mailto:kernelnewbies- > >> bounces+jharan=bytemobile.com@xxxxxxxxxxxxxxxxx] On Behalf Of > >> Abhishek Bist > >> Sent: Monday, April 27, 2015 6:19 AM > >> To: kernelnewbies@xxxxxxxxxxxxxxxxx > >> 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@xxxxxxxxxxxxxxxxx > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@xxxxxxxxxxxxxxxxx > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
