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