SpinLock/Mutex : Difference ?
in [Win32 Kernel]
|
From: Pavel A. on 18 Dec 2009 14:37 For working in huge companies like that, pure technical merits too often are not enough to stay in. Need to have strong "communication skills" in order to sell your idea. Good luck. --pa "tanix" <tanix(a)mongo.net> wrote in message news:hggafe$ot7$2(a)news.eternal-september.org... > 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. >
From: Hugo gleaves on 18 Dec 2009 14:56 Well let me be perfectly clear I am not suggesting or advocating any interaction with any kernel mode mechanisms. If you work with shared mapped memory a great deal as we do, then you need very fast means of locking shared data structures, especially of this is happening very often. For example we have a shared heap library that we designed, it obvioulsy must handle safe updates to heap control metadata by many threads and many processes at the same time, perhaps tens of thousands of times a second. A mutex simply can't deliver the speed and efficiency. Getting/releaseing the Mutex costs far far more CPU cycles then updating four fields in a little structure and a pointer or two. Most people perhaps use shared memory for the odd neat trick or some useful little mechanism, but if you rely on it as a vehicle for sharing/storing many gigs of data then you really do need speedy locks. Hugo "tanix" wrote: > 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. > > . >
From: Hugo gleaves on 18 Dec 2009 16:36 Man, what a story, I have to say I've seen that kind of thing too. In my view anyone who suggests anything like that has no appreciation of the engineering nor any professional maturity. However, I have to ask how is that fool's suggestion "pretty much the same idea as in this thread"? I am totally opposed to the kind of thing he was suggesting. All I said is that user-mode code sometimes has a real need for a very fast locking mechanism, I never once said that user mode code should in any way access or use or interfere with kernel mode mechanisms, I would never suggest such a thing. But it is naive to believe that non-kernel mode developers never need very fast read/write locks. Even the OS kernel does not support read/write spinlocks, but would it not be good if it did? Surely there are scenarios within driver design where a read spinlock would be useful? Hugo "Pavel A." wrote: > For working in huge companies like that, pure technical merits too often > are not enough to stay in. Need to have strong "communication skills" > in order to sell your idea. Good luck. > --pa > > > "tanix" <tanix(a)mongo.net> wrote in message > news:hggafe$ot7$2(a)news.eternal-september.org... > > 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. > >
From: m on 18 Dec 2009 20:40 FYI reference implementations of shared reader, single writer locks are widely available on usernet - the archives of this NG have at least two threads on the topic and I am sure there is more out there. IMHO, a minimal implementation can be created with three volatile long variable in less than 50 lines of code so the APIs provided by MS (AcquireSRWLockExclusive and friends) are almost redundant http://msdn.microsoft.com/en-us/library/aa904937(VS.85).aspx "Hugogleaves(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 é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: Alexander Grigoriev on 18 Dec 2009 22:12
CRITICAL_SECTION is VERY fast when there is no contention. IF ther is a contention, it gives you _limited_ busy spin wait, and then, if it doesn't work out, you have to go to kernel anyway. "Hugo gleaves(a)hotmail.com>" <hugh<underbar> wrote in message news:D3ADE2F2-4CC9-474A-BCCF-DD560849C259(a)microsoft.com... > Man, what a story, I have to say I've seen that kind of thing too. In my > view > anyone who suggests anything like that has no appreciation of the > engineering > nor any professional maturity. > > However, I have to ask how is that fool's suggestion "pretty much the same > idea as in this thread"? > > I am totally opposed to the kind of thing he was suggesting. > > All I said is that user-mode code sometimes has a real need for a very > fast > locking mechanism, I never once said that user mode code should in any way > access or use or interfere with kernel mode mechanisms, I would never > suggest > such a thing. > > But it is naive to believe that non-kernel mode developers never need very > fast read/write locks. > > Even the OS kernel does not support read/write spinlocks, but would it not > be good if it did? Surely there are scenarios within driver design where a > read spinlock would be useful? > > Hugo > > > "Pavel A." wrote: > >> For working in huge companies like that, pure technical merits too often >> are not enough to stay in. Need to have strong "communication skills" >> in order to sell your idea. Good luck. >> --pa >> >> >> "tanix" <tanix(a)mongo.net> wrote in message >> news:hggafe$ot7$2(a)news.eternal-september.org... >> > 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. >> > |