- Recursive spinlock - 25 Updates
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 12:50PM -0700 On 5/11/2020 9:53 PM, Bonita Montero wrote: >> he lie? > Give the sourcecode as well as a benchmark. > And Windows does it with a fixed spin-count. Why do you say that? Humm... https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-setcriticalsectionspincount This allows the spin count to be modified. If this should work my |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 12:57PM -0700 On 5/12/2020 12:50 PM, Chris M. Thomasson wrote: > Why do you say that? Humm... > https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-setcriticalsectionspincount > This allows the spin count to be modified. [...] Bonita, calm down and realize that you are having some real trouble with understanding adaptive mutexs. You don't "seem" to have any experience with them. Btw, please run your code through a race detector to kill off the bugs. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 12:59PM -0700 On 5/11/2020 11:49 PM, Bonita Montero wrote: >> and PTHREAD_MUTEX_ADAPTIVE_NP is fastest there for most things. > Write a benchmark. > Or look at Windows. Windows has a fixed spin-count. [...] https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-setcriticalsectionspincount [...] |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 01:00PM -0700 On 5/11/2020 4:05 AM, Bonita Montero wrote: >> But if the slow path is taken always, the locks are held for a long >> time always. > Doesn't change what I said. lol. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:06PM +0200 > Why do you say that? Humm... > https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-setcriticalsectionspincount > This allows the spin count to be modified. You're so stupid, dude. That's the same what my code allows. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:08PM +0200 > Bonita, calm down and realize that you are having some real trouble with > understanding adaptive mutexs. You don't "seem" to have any experience > with them. My mutex exactly does the same what the Windows mutex does. > Btw, please run your code through a race detector to kill off the bugs. Tell me what the bugs are. There aren't any. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:09PM +0200 >> Write a benchmark. >> Or look at Windows. Windows has a fixed spin-count. [...] > https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-setcriticalsectionspincount Take my code _which_does_the_same_like_the_Windows_critical_section_ _with_spin_lock_does_ and show wich are the appropriate parameters which show the benefit of spinning ! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 01:09PM -0700 On 5/12/2020 12:58 AM, Bonita Montero wrote: >> using a race detector, it will find your bugs. Try Relacy..." > Races are absolutely legal in this situation and, if your theory > is right, should be prevented by an appropriate spin-count. Huh? What does the spin-count have to do with a nasty race condition? You do not seem to know what you are talking about. Think of a race condition where the wrong memory barrier was used. > And don't believe what Chris says; he is an underskilled developer > with a lot of ideas which are not thought to the end. lol. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 01:11PM -0700 On 5/12/2020 1:08 PM, Bonita Montero wrote: >> with understanding adaptive mutexs. You don't "seem" to have any >> experience with them. > My mutex exactly does the same what the Windows mutex does. You just tried to tell us that Windows has a fixed spin count. ;^o >> Btw, please run your code through a race detector to kill off the bugs. > Tell me what the bugs are. There aren't any. Did you finish correcting them all? You made several of them. Btw, Relacy can be found here: https://github.com/dvyukov/relacy Trust me, it helps. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 01:12PM -0700 On 5/12/2020 1:06 PM, Bonita Montero wrote: >> This allows the spin count to be modified. > You're so stupid, dude. > That's the same what my code allows. You are having memory loss. You said that windows has a fixed spin count! In reality, it can be adjusted. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:14PM +0200 >> My mutex exactly does the same what the Windows mutex does. > You just tried to tell us that Windows has a fixed spin count. ;^o You don't understand what I mean with "fixed spin-count". I don't mean that it isn't adjustable after creation of the mutex. I mean that it isn't adaptive like with Linux. > Relacy can be found here: > https://github.com/dvyukov/relacy > Trust me, it helps. I'm pretty sure you haven't read my code. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:14PM +0200 >> That's the same what my code allows. > You are having memory loss. You said that windows has a fixed spin > count! In reality, it can be adjusted. Read my other posting ! |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:17PM +0200 >> Races are absolutely legal in this situation and, if your theory >> is right, should be prevented by an appropriate spin-count. > Huh? What does the spin-count have to do with a nasty race condition? The race-condition on the lock-counter determines which thread acquires the mutex first. > You do not seem to know what you are talking about. > Think of a race condition where the wrong memory barrier was used. I've used correct memory-barriers: acquire on successful locks, relase on successful unlocks, otherewise releaxed when I repeat because the lock-counter has changed meanwhile. Sorry, dude, read the code firs before you tell nonsense. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 01:17PM -0700 On 5/12/2020 1:14 PM, Bonita Montero wrote: >> https://github.com/dvyukov/relacy >> Trust me, it helps. > I'm pretty sure you haven't read my code. No. I read where you made some corrections. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 01:18PM -0700 On 5/12/2020 1:09 PM, Bonita Montero wrote: > Take my code _which_does_the_same_like_the_Windows_critical_section_ > _with_spin_lock_does_ and show wich are the appropriate parameters > which show the benefit of spinning ! You said Windows uses a fixed spin count. It can be dynamically altered. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:19PM +0200 >> I'm pretty sure you haven't read my code. > No. I read where you made some corrections. You make assumptions on my code without reading it. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:20PM +0200 >> _with_spin_lock_does_ and show wich are the appropriate parameters >> which show the benefit of spinning ! > You said Windows uses a fixed spin count. It can be dynamically altered. Yes, it does. But you don't know what this means. This doesn't mean that the spin-count isn't adjustable. This does mean that it isn't adaptive, i.e. self-adjusted, like under Linux. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:22PM +0200 > Yes, it does. But you don't know what this means. This doesn't mean > that the spin-count isn't adjustable. This does mean that it isn't > adaptive, i.e. self-adjusted, like under Linux. If you would have really read the thead, especially what Öö Tiib said, there would have been no doubt what we were talking about. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 10:28PM +0200 > You make assumptions on my code without reading it. Here it is again. Now with some POSIX-compatibility. Unfortunately I'm not familiar how to write inline-assembly for g++. So I've just written a spendCycles-routine which should spend 8 clock-cycles for each iteration on my CPU. On other CPUs this might be different. So mayme someone here could supply some inline-assembly to make the code of spendCycles timing-equivalent for Li #if defined(_MSC_VER) #define _CRT_SECURE_NO_WARNINGS #include <Windows.h> #elif defined(__unix__) #include <semaphore.h> 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment