SpinLock/Mutex : Difference ?
in [Win32 Kernel]
|
From: m on 4 Dec 2009 20:48 While that it is true for spin locks in KM, it is not true of spin locks in general on a preemptive multi-tasking OS (ie Windows). Maybe I should have assumed that the OP meant NT KM spinlocks thou ;) "Daniel Terhell" <daniel(a)resplendence.com> wrote in message news:emRp7$LdKHA.2188(a)TK2MSFTNGP04.phx.gbl... > "m" <m(a)b.c> wrote in message news:eP9kilIdKHA.6096(a)TK2MSFTNGP02.phx.gbl... >> The loop will consume all 100% of a single CPU until the lock is >> acquired, the thread is interrupted by a higher priority thread or the >> thread quantum ends (and the OS schedules another thread). >> > > That information is incorrect, on Windows a spinlock raises to > DISPATCH_LEVEL (or higher) so it is not possible to get interrupted by any > thread. It's not even possible for the thread to finish its quantum while > it spins or for the dispatcher to schedule another thread on the same CPU. > It can get interrupted by an ISR but it will return (to the spinning > state) as soon as the ISR has executed and returns control. > > //Daniel > >
From: Hugo gleaves on 18 Dec 2009 04:42 The idea of a spinlock is to ensure secure access/updates to some datum, usually for operations that are very very brief. So although some other thread/process may have to "spin" for a time, the time is deemed to brief as to be not a serious performance issue. The kind of operations that might be suited to a spinlock protection are: 1) Updating several fields atomically in some shared structure. 2) Adding/removing an entry from a shared list. As Don says a Mutex is much more sophisticated and expensive and although very uself in Win32 programming is no match for a spinlock when it comes to raw speed (this is why device drivers use them). The real question here is why has MS not provided developers with a spinlock API for user mode code? I had to hand craft such a beast in C, it has to support: 1) Nested locking (a spinlock can be acquired 'n' times and must then be released 'n' times). 2) Read/Write locking modes. 3) Not end up dragging its heels because of these needs. If you do a lot of work with shared/mapped memory as we do, then such an API is very important, if you rely on Mutexes it will cost dearly, also the interlock functions alone wont let you easily do the above (but they do provide the foundation). I've been interested for some time in seeing open source or public domain implementations of a user-mode spinlock API (one that is truly tested on multicore H/W) but there seems to be absolutely nothing, what we have seems to be pretty good but it is pretty complex and I worry sometimes... ;) "o0Zz" wrote: > Thank you very much ! > > "Daniel Terhell" <daniel(a)resplendence.com> a écrit dans le message de groupe > de discussion : emRp7$LdKHA.2188(a)TK2MSFTNGP04.phx.gbl... > > "m" <m(a)b.c> wrote in message news:eP9kilIdKHA.6096(a)TK2MSFTNGP02.phx.gbl... > >> The loop will consume all 100% of a single CPU until the lock is > >> acquired, the thread is interrupted by a higher priority thread or the > >> thread quantum ends (and the OS schedules another thread). > >> > > > > That information is incorrect, on Windows a spinlock raises to > > DISPATCH_LEVEL (or higher) so it is not possible to get interrupted by any > > thread. It's not even possible for the thread to finish its quantum while > > it spins or for the dispatcher to schedule another thread on the same CPU. > > It can get interrupted by an ISR but it will return (to the spinning > > state) as soon as the ISR has executed and returns control. > > > > //Daniel > > > > > . >
From: tanix on 18 Dec 2009 08:33 In article <574400EE-AFAF-4620-BDDD-7E49608392E0(a)microsoft.com>, =?Utf-8?B?SHVnbw==?= gleaves(a)hotmail.com> <hugh<underbar> wrote: >The idea of a spinlock is to ensure secure access/updates to some datum, >usually for operations that are very very brief. So although some other >thread/process may have to "spin" for a time, the time is deemed to brief as >to be not a serious performance issue. > >The kind of operations that might be suited to a spinlock protection are: > >1) Updating several fields atomically in some shared structure. >2) Adding/removing an entry from a shared list. > >As Don says a Mutex is much more sophisticated and expensive and although >very uself in Win32 programming is no match for a spinlock when it comes to >raw speed (this is why device drivers use them). > >The real question here is why has MS not provided developers with a spinlock >API for user mode code? I bet there is a reason. I bet by the time you do a switching from user mode to kernel mode, the whole performance gain becomes negligible in comparison. I thought mutex is already quite an efficient way of doing locking. Once you are in user mode trying to use a kernel mode spinlock equivalent somehow does not make much sense. MS recommends to hold a spin lock for no more than 50 microsecs if I recall correctly. >I had to hand craft such a beast in C, it has to support: > >1) Nested locking (a spinlock can be acquired 'n' times and must then be >released 'n' times). >2) Read/Write locking modes. >3) Not end up dragging its heels because of these needs. > >If you do a lot of work with shared/mapped memory as we do, then such an API >is very important, if you rely on Mutexes it will cost dearly, also the >interlock functions alone wont let you easily do the above (but they do >provide the foundation). > >I've been interested for some time in seeing open source or public domain >implementations of a user-mode spinlock API (one that is truly tested on >multicore H/W) but there seems to be absolutely nothing, what we have seems >to be pretty good but it is pretty complex and I worry sometimes... Do you have estimates on performance comparison between your app level spin lock and a regular mutex? >;) > > >"o0Zz" wrote: > >> Thank you very much ! >> >> "Daniel Terhell" <daniel(a)resplendence.com> a écrit dans le message de groupe > >> de discussion : emRp7$LdKHA.2188(a)TK2MSFTNGP04.phx.gbl... >> > "m" <m(a)b.c> wrote in message news:eP9kilIdKHA.6096(a)TK2MSFTNGP02.phx.gbl... >> >> The loop will consume all 100% of a single CPU until the lock is >> >> acquired, the thread is interrupted by a higher priority thread or the >> >> thread quantum ends (and the OS schedules another thread). >> >> >> > >> > That information is incorrect, on Windows a spinlock raises to >> > DISPATCH_LEVEL (or higher) so it is not possible to get interrupted by any >> > thread. It's not even possible for the thread to finish its quantum while >> > it spins or for the dispatcher to schedule another thread on the same CPU. >> > It can get interrupted by an ISR but it will return (to the spinning >> > state) as soon as the ISR has executed and returns control. >> > >> > //Daniel >> > >> > >> . -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, organized by major topics of language, tools, methods, techniques.
From: Alexander Grigoriev on 18 Dec 2009 09:56 By definition, spinlock is a busy loop. It only makes sense to do if the spinlock owner is guaranteed to never get preempted by another thread. In kernel mode, this is done by setting IRQL to DISPATCH_LEVEL. In user mode, this is not possible. CRITICAL_SECTION provide an option of limited spinning in case of contention, if you expect that the CS will mostly be held for very short time. "Hugo gleaves(a)hotmail.com>" <hugh<underbar> wrote in message news:574400EE-AFAF-4620-BDDD-7E49608392E0(a)microsoft.com... > The idea of a spinlock is to ensure secure access/updates to some datum, > usually for operations that are very very brief. So although some other > thread/process may have to "spin" for a time, the time is deemed to brief > as > to be not a serious performance issue. > > The kind of operations that might be suited to a spinlock protection are: > > 1) Updating several fields atomically in some shared structure. > 2) Adding/removing an entry from a shared list. > > As Don says a Mutex is much more sophisticated and expensive and although > very uself in Win32 programming is no match for a spinlock when it comes > to > raw speed (this is why device drivers use them). > > The real question here is why has MS not provided developers with a > spinlock > API for user mode code? > > I had to hand craft such a beast in C, it has to support: > > 1) Nested locking (a spinlock can be acquired 'n' times and must then be > released 'n' times). > 2) Read/Write locking modes. > 3) Not end up dragging its heels because of these needs. > > If you do a lot of work with shared/mapped memory as we do, then such an > API > is very important, if you rely on Mutexes it will cost dearly, also the > interlock functions alone wont let you easily do the above (but they do > provide the foundation). > > I've been interested for some time in seeing open source or public domain > implementations of a user-mode spinlock API (one that is truly tested on > multicore H/W) but there seems to be absolutely nothing, what we have > seems > to be pretty good but it is pretty complex and I worry sometimes... > > ;) > > > "o0Zz" wrote: > >> Thank you very much ! >> >> "Daniel Terhell" <daniel(a)resplendence.com> a ecrit dans le message de >> groupe >> de discussion : emRp7$LdKHA.2188(a)TK2MSFTNGP04.phx.gbl... >> > "m" <m(a)b.c> wrote in message >> > news:eP9kilIdKHA.6096(a)TK2MSFTNGP02.phx.gbl... >> >> The loop will consume all 100% of a single CPU until the lock is >> >> acquired, the thread is interrupted by a higher priority thread or the >> >> thread quantum ends (and the OS schedules another thread). >> >> >> > >> > That information is incorrect, on Windows a spinlock raises to >> > DISPATCH_LEVEL (or higher) so it is not possible to get interrupted by >> > any >> > thread. It's not even possible for the thread to finish its quantum >> > while >> > it spins or for the dispatcher to schedule another thread on the same >> > CPU. >> > It can get interrupted by an ISR but it will return (to the spinning >> > state) as soon as the ISR has executed and returns control. >> > >> > //Daniel >> > >> > >> . >>
From: tanix on 18 Dec 2009 11:26
In article <OFiPAJ$fKHA.1112(a)TK2MSFTNGP04.phx.gbl>, "Alexander Grigoriev" <alegr(a)earthlink.net> wrote: >By definition, spinlock is a busy loop. It only makes sense to do if the >spinlock owner is guaranteed to never get preempted by another thread. In >kernel mode, this is done by setting IRQL to DISPATCH_LEVEL. In user mode, >this is not possible. Good point. Actually, when I was doing a contract with Intel on a multi-gigabit network card, there was one guy that was suggesting to do something totally out of the wall in my view. Pretty much the same idea as in this thread. They were trying to squeze out as much performance as possible. So, this "smart", fat blob, came up with the idea to manipulate the kernel level synchronization objects from the app level, such as resetting the count of kernel level semaphores under some contitions. On a weekly project meeting I told him: you will never prove this thing is going to work. That is the whole point with semaphores. They have been mathematically proven to work. Once you start resetting the counts at will, outside of the normal semaphore mechanics, you'll be fixing this thing for years to come. The result? They fired me. Not him. I wonder if they were ever able to make that network card to work. When they gave me this project to create a hack to manipulate the kernel level structures from the user mode, and gave me a couple of weeks to do that, I could not believe these smart donkeys. It takes YEARS to work on things like these. These are some of the central concepts in O/S design and the very idea of separation of kernel and user mode. I nearly flipped out when manager told me my "project". Some people really need their brains examined. Where did they get their estimates on "improving performance" by slaughtering some of the most fundamental concepts in o/s design and architecture just escapes me. >CRITICAL_SECTION provide an option of limited spinning in case of >contention, if you expect that the CS will mostly be held for very short >time. > > >"Hugo gleaves(a)hotmail.com>" <hugh<underbar> wrote in message >news:574400EE-AFAF-4620-BDDD-7E49608392E0(a)microsoft.com... >> The idea of a spinlock is to ensure secure access/updates to some datum, >> usually for operations that are very very brief. So although some other >> thread/process may have to "spin" for a time, the time is deemed to brief >> as >> to be not a serious performance issue. >> >> The kind of operations that might be suited to a spinlock protection are: >> >> 1) Updating several fields atomically in some shared structure. >> 2) Adding/removing an entry from a shared list. >> >> As Don says a Mutex is much more sophisticated and expensive and although >> very uself in Win32 programming is no match for a spinlock when it comes >> to >> raw speed (this is why device drivers use them). >> >> The real question here is why has MS not provided developers with a >> spinlock >> API for user mode code? >> >> I had to hand craft such a beast in C, it has to support: >> >> 1) Nested locking (a spinlock can be acquired 'n' times and must then be >> released 'n' times). >> 2) Read/Write locking modes. >> 3) Not end up dragging its heels because of these needs. >> >> If you do a lot of work with shared/mapped memory as we do, then such an >> API >> is very important, if you rely on Mutexes it will cost dearly, also the >> interlock functions alone wont let you easily do the above (but they do >> provide the foundation). >> >> I've been interested for some time in seeing open source or public domain >> implementations of a user-mode spinlock API (one that is truly tested on >> multicore H/W) but there seems to be absolutely nothing, what we have >> seems >> to be pretty good but it is pretty complex and I worry sometimes... >> >> ;) >> >> >> "o0Zz" wrote: >> >>> Thank you very much ! >>> >>> "Daniel Terhell" <daniel(a)resplendence.com> a ecrit dans le message de >>> groupe >>> de discussion : emRp7$LdKHA.2188(a)TK2MSFTNGP04.phx.gbl... >>> > "m" <m(a)b.c> wrote in message >>> > news:eP9kilIdKHA.6096(a)TK2MSFTNGP02.phx.gbl... >>> >> The loop will consume all 100% of a single CPU until the lock is >>> >> acquired, the thread is interrupted by a higher priority thread or the >>> >> thread quantum ends (and the OS schedules another thread). >>> >> >>> > >>> > That information is incorrect, on Windows a spinlock raises to >>> > DISPATCH_LEVEL (or higher) so it is not possible to get interrupted by >>> > any >>> > thread. It's not even possible for the thread to finish its quantum >>> > while >>> > it spins or for the dispatcher to schedule another thread on the same >>> > CPU. >>> > It can get interrupted by an ISR but it will return (to the spinning >>> > state) as soon as the ISR has executed and returns control. >>> > >>> > //Daniel >>> > >>> > >>> . -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, organized by major topics of language, tools, methods, techniques. |