- Mutex with Spin-Count - 8 Updates
- Recursive spinlock - 15 Updates
- neoGFX (C++) ECS-based sprite animation - 1 Update
- neoGFX animation is as simple as... - 1 Update
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 02:08PM -0700 On 5/12/2020 2:06 PM, Bonita Montero wrote: >> Sometime today, or tomorrow. > Sorry, that's like debugging hello world. Read the code and you'll > see in 10min that is correct (aside from non-handled resource-erors). Na. I read the code in detail during the porting process. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 11:19PM -0700 On 5/12/2020 11:08 PM, Bonita Montero wrote: >> Fwiw, this is a bug. You are misusing sem_wait. ... > No. Yes. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 02:22PM -0700 On 5/12/2020 2:10 PM, Bonita Montero wrote: >>> see in 10min that is correct (aside from non-handled resource-erors). >> Na. I read the code in detail during the porting process. > Which porting-process ? To create a Relacy test unit out of it. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:17AM +0200 >> Also not necessary for the purpose of this code, that's while I skipped >> it. > So anyone who disagrees with you is stupid. Bye bye... *PLONK* His objections simply have nothing to do with the question discussed, i.e. whether adaptive mutexes make sense. |
| red floyd <no.spam.here@its.invalid>: May 17 07:59PM -0700 On 5/17/2020 9:17 AM, Bonita Montero wrote: >> mode *cough*ncurses*cough* > I know when EINTR-handling is appropriate and when not. > You don't. I'm so glad you know that my 38 years of Unix programming experience haven't taught me anything... Screw you. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:29AM +0200 >> Sorry, there's no need for Relacy here because the mutex is simple. > It found a memory leak and a dead lock condition wrt EINTR. You're such a mega-idiot. That's not industrial-level code, it's expermental to allow to prove Öö Tiibs assumptions. And for this puprose it is completely adequate. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:14AM +0200 > I finally implemented the Windows version of the mutex using a Relacy > test unit. It works fine. However, the POSIX version needs to properly > handle sem_wait return values wrt errno, Boy, you're so strupid. That's not industrial-level code for relase to a product; so there's no need to handle EINTR. > I had to add a destructor to the Semaphore class to close the handle. Also not necessary for the purpose of this code, that's while I skipped it. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 03:49PM -0700 On 5/12/2020 1:49 PM, Bonita Montero wrote: > void release(); > void wait(); > private: [...] Relacy also reports resource leaks. You never destroy the Semaphore. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: May 14 06:29AM -0700 Tiib writes: >> [redacted] > Why should I write you benchmarks when you post groundless > bullshit? Benchmarks written by me can't cure your stupidity. I think of <unnamed> as a kind of netnews intelligence test. The smarter someone is, the sooner they will cease responding to any of <unnamed>'s postings. |
| Ian Collins <ian-news@hotmail.com>: May 12 06:53PM +1200 On 12/05/2020 18:43, Öö Tiib wrote: > any doubt. Linux is open source, glibc is open source and > PTHREAD_MUTEX_ADAPTIVE_NP is fastest there for most things. > Observe internet. https://stackoverflow.com/questions/19863734/what-is-pthread-mutex-adaptive-np The top reply is from Kaz. -- Ian. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 06:53AM +0200 > Kaz Kylheku who originally invented that PTHREAD_MUTEX_ADAPTIVE_NP has > said that it has spin count adjusted by such estimator. Why should > he lie? Give the sourcecode as well as a benchmark. And Windows does it with a fixed spin-count. If this should work my benchmark should do the same given appropriate paramters. So compile my benchmark, experiment with different parameters and give a proof. I'll bet there will be no proof from you. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 01:58PM +0200 > I won't sure compile it. It is some kind of newbie crap with > non-static getters for static members. ... The both counters need to be non-static, not the accessors static. But that has nothing to do with if the code is suitable to proof something you assume. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 09:03AM +0200 > Windows is closed source garbage. Microsoft is awful, look what they > did with Skype. It was great, but now Zoom beats it anytime in all > aspects. My code does the same Windows does and it is not closed-souce. And some other implementations also have a fixed spin-count. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 12 09:58AM +0200 > Chris M. Thomasson gave you advice "Please implement your code > 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. And don't believe what Chris says; he is an underskilled developer with a lot of ideas which are not thought to the end. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 01:31PM -0700 On 5/12/2020 1:20 PM, Bonita Montero wrote: > 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. Ahhhh. I see. |
| "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 |
| 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 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. |
| 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: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. |
| "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. |
| "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. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 12 11:03PM +0100 https://www.youtube.com/watch?v=APygeBnXRaU&feature=youtu.be -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 13 11:51AM On Wed, 2020-05-13, Christian Gollwitzer wrote: >> auto explosion = ecs.create_entity(archetypes::explosion, >> explosionMaterial, explosionAnimation); > IOW, to you it may seem simple, to me it is just gibberish. I guess C++ isn't for everyone. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment