- Recursive spinlock - 10 Updates
- Custom allocator not working with gcc - 11 Updates
- invalid initialization of non-const reference of type - 4 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: May 10 07:36AM +0200 > Mostly true. However, an adaptive lock, that spins a couple of times > before it actually blocks can be useful in userland. The PAUSE > instruction can help out here. No, this also doesn't make sense. That's because if there's a high likehood that spinning gives success the locks are usually held only a very short time. And if they are there's a low likehood of collision so that you can drop spinning. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 10 07:45AM +0200 > Which is what my recursive spinlock does; Bonita should try looking at > the fucking code before commenting. Then don't talk about a spinlock. Spinlocks aren't composite-locks that incorporate kernel-waiting but just spinning. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 10 06:51AM +0100 On 10/05/2020 06:45, Bonita Montero wrote: >> Which is what my recursive spinlock does; Bonita should try looking at the fucking code before commenting. > Then don't talk about a spinlock. Spinlocks aren't composite-locks > that incorporate kernel-waiting but just spinning. B U L L S H I T /Flibble -- "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." |
| Bonita Montero <Bonita.Montero@gmail.com>: May 10 07:55AM +0200 >> Then don't talk about a spinlock. Spinlocks aren't composite-locks >> that incorporate kernel-waiting but just spinning. > B U L L S H I T Look at the Wikipedia, dude. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 10 04:39AM -0700 On 5/9/2020 10:36 PM, Bonita Montero wrote: >> before it actually blocks can be useful in userland. The PAUSE >> instruction can help out here. > No, this also doesn't make sense. Adaptive locks make sense. A lot of OS's use them. https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initializecriticalsectionandspincount [...] |
| Bonita Montero <Bonita.Montero@gmail.com>: May 10 01:49PM +0200 > Adaptive locks make sense. A lot of OS's use them. Tell me another OS than Windows that uses them. I told you the reason they don't make sense. Again: if the likehood you get hold of the lock by spinning is high the lock is only held a very short time. If it is held a very short time, the likehood of a collision of two threads is low. So spinning doesn't make sense. > https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initializecriticalsectionandspincount That's just a stupid Microsoft-idea. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 10 05:00AM -0700 On 5/10/2020 4:49 AM, Bonita Montero wrote: >> Adaptive locks make sense. A lot of OS's use them. > Tell me another OS than Windows that uses them. Solaris. And there are others. > low. So spinning doesn't make sense. >> https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initializecriticalsectionandspincount > That's just a stupid Microsoft-idea. Why do you think that Microsoft invented adaptive mutexs? lol. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 10 02:07PM +0200 Mutexes with spinning are just a stupid idea and are not thought to the end in the sense i told. |
| "Öö Tiib" <ootiib@hot.ee>: May 10 05:47AM -0700 On Sunday, 10 May 2020 15:07:22 UTC+3, Bonita Montero wrote: > Mutexes with spinning are just a stupid idea and are not thought > to the end in the sense i told. So you again repeatedly write a fundamental claim with none ground provided. The claim is that both POSIX (PTHREAD_MUTEX_ADAPTIVE_NP) and Win32 (SetCriticalSectionSpinCount) are stupid. No research ... benchmarks ... theoretical calculations ... links to such ... just *stupid* and *period*. And that for cascade of posts. Yawn. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 10 02:55PM +0200 > No research ... benchmarks ... theoretical calculations ... links > to such ... just *stupid* and *period*. And that for cascade of posts. > Yawn. I told you why. Try to argue against that. |
| Juha Nieminen <nospam@thanks.invalid>: May 10 05:52AM >> using value_type = T; > What about in C++98? typedef T value_type; |
| Juha Nieminen <nospam@thanks.invalid>: May 10 05:54AM > code even if its test code, otherwise I'd have to throw process control, > networking and half a dozen other subsystems which "pure" c++ doesn't support > out the window. When you post code here, make sure it actually compiles. Your code did not compile for me because of that "u_long". |
| Juha Nieminen <nospam@thanks.invalid>: May 10 06:01AM > Each to their own. unsigned long is long winded So? What's your point? > u_long is short and to the point and standard on unix. Why deliberately restrict your code to a single environment when with an extremely small change you can make it more portable? It makes no sense. I find it quite ironic that you want your code to be C++98 conforming to increase support for older compilers used in older systems... but then you don't care that your code is unix-only. |
| boltar@nowhere.co.uk: May 10 08:33AM On Sat, 9 May 2020 21:50:47 +0200 >The most famous is 64 bit Windows. Pointers are 64 bit - as expected - >but long is 32 bit. So casting a pointer to unsigned long looses half of >the information. Ok, I didn't know that. It just proves to me yet again what a joke that operating system and its tools are. |
| boltar@nowhere.co.uk: May 10 08:35AM On Sun, 10 May 2020 06:01:25 -0000 (UTC) >boltar@nowhere.co.uk wrote: >> Each to their own. unsigned long is long winded >So? What's your point? That is the point. Unless you think all longs should have been specified as "signed long" just to make it clearer? >Why deliberately restrict your code to a single environment when >with an extremely small change you can make it more portable? >It makes no sense. I don't code for Windows. If it doesn't compile on it I couldn't care less nor do I have any way to test whether it does even if I did care. |
| boltar@nowhere.co.uk: May 10 08:41AM On Sat, 09 May 2020 14:17:48 -0700 >boltar@nowhere.co.uk writes: > typedef __u_long u_long; >Personally, I fail to see what's convenient about them. "unsigned long" So presumable you'd prefer to have to type "signed long" or "signed int" instead of long or int then too? >C) implementation. Using the name "u_long" adds no information. If Using ++i adds no information over i = i + 1. Whats your point? >(I'm mildly curious why those headers define those typedefs. There are >probably historical reasons.) I imagine people found them useful. >that can be defined differently on different implementations (like >size_t and time_t, for example) are useful. Typedefs that simply >provide shorter names for existing types are not, in my opinion. That is indeed your opinion. Other peoples opinions differ. >Sure, you can write gratuitously non-portable code if you like. Nobody Well it compiled on 2 versions of gcc on 2 different linux distros and on MacOS Mojave and Catalina. Thats portable enough for me. If it doesn't compile on VC++ thats too bad, I can neither test for that nor do I give a damn frankly. >Do you have some reason to prefer writing "u_long" over "unsigned long"? Presumably you write i = i + 1 instead of using pre/postfix increment operators. Otherwise you wouldn't ask such a stupid question. >> Any more stupid questions? >Be less rude. I'll pose that question again. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 10 10:59AM +0200 Some time ago I wrote an allocator that maps either to mmap() (POSIX) or VirtualAloc() (Windows). It is compatible wit compilers before C++2017 and since C++2017. Unfortunately I found that the allocator was used via typename allocator_traits<myalloc>::template rebind_alloc<T> by std::vector but I thought that it would be only used for a single allocation by std::vector. So it wasn't usable for me anymore. But here's the code: #ifdef _MSC_VER #include <Windows.h> #elif __unix__ #include <sys/mman.h> 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment