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