RE: Semaphore and Spinlock
-Original Message- From: kernelnewbies-boun...@kernelnewbies.org [mailto:kernelnewbies- boun...@kernelnewbies.org] On Behalf Of Ruben Sent: Monday, April 27, 2015 12:10 PM To: kernelnewbies@kernelnewbies.org Subject: Re: Semaphore and Spinlock 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. 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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ 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
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. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore and Spinlock
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@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. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: Semaphore and Spinlock
-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 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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore and Spinlock
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
