- Custom allocator not working with gcc - 10 Updates
- Recursive spinlock - 15 Updates
| Ian Collins <ian-news@hotmail.com>: May 10 09:21AM +1200 On 09/05/2020 22:31, Juha Nieminen wrote: >> Also, don't mix iostreams with C stdio. > As long as they are synced (which is possible via standard library) > it becomes merely a question of program design rather than validity. They weren't here. I'm happy the that bit of advice is generally valid. The nonsense arguments that followed about format specifiers would have been avoided if he'd just use iostreams! -- Ian |
| Juha Nieminen <nospam@thanks.invalid>: May 10 02:09PM > That is the point. Unless you think all longs should > have been specified as "signed long" just to make it > clearer? *What* is the point? I don't get it. What's with this obsession that beginners have with shorter code? > 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. If you don't care about standards, why were you talking about Posix earlier, then? Either way, if you want people *here* to help you, you should post code that actually compiles. Using non-standard code is a way to make sure that it won't compile and people will be less helpful. |
| boltar@nowhere.co.uk: May 11 08:46AM On Sun, 10 May 2020 12:28:16 +0200 >> Plenty of old systems in companies have old compilers. A company I worked for >> until 2019 was still on C++ 2003. Calls to upgrade fell on deaf ears. >Are you writing code for them? If not, why do you care? C++11 is a I care for the same reason I keep my C skills up to date - you never know what a future job may require and I hedge my bets. I'm not going to turn down work simply because they use an old version of C++. >> Each to their own. unsigned long is long winded, u_long is short and to the >> point and standard on unix. >It is not "standard" - common on *nix, but not standard (neither POSIX De facto standard then. |
| 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. |
| Ian Collins <ian-news@hotmail.com>: May 10 09:26AM +1200 >>> Many thanks >> Your code as posted won't compile (the string construction). > It compiles fine on 3 unix compilers. I'm guessing you're using VC++. It needed -std=c++17 to compile with gcc and clang. I don't use windows. >> with C stdio. > There's nothing wrong with mixing iostreams with C stdio and there hasn't been > for years. If, as Juha pointed out, they are synchronised. -- Ian. |
| boltar@nowhere.co.uk: May 11 09:45AM On Mon, 11 May 2020 20:57:08 +1200 >> Clang makes them easy , it turns out using them with gcc is a PITA. Oh well. >There's no difference in this case between the two compilers (or any >other assuming the code meets the standard's requirements). Apart from the code works in Clang but not gcc. And if I don't inherit from allocator it doesn't even compile in gcc never mind work. So no, no difference at all. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 09 08:30PM +0100 >>any C++ compiler), and it will be the correct size for pointers - >>something that does not always apply to "unsigned long". > Give somes example architectures when it wouldn't apply? 64-bit MS Windows systems usually have a 32-bit long. -- Ben. |
| Ian Collins <ian-news@hotmail.com>: May 11 08:57PM +1200 >> custom allocators; they seem painful and useful only in rare >> circumstances. > Clang makes them easy , it turns out using them with gcc is a PITA. Oh well. There's no difference in this case between the two compilers (or any other assuming the code meets the standard's requirements). -- Ian. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: May 10 02:45AM -0700 >>> Any more stupid questions? >>Be less rude. > I'll pose that question again. Bye. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 10 09:41AM > 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. For the record, I reason the same way. A lot of C++ code, probably most and certainly mine, is not intended to be compiled on Windows. Still, it's not pedagogical to include unnecessary Unixisms with questions to comp.lang.c++ because everyone will comment on it and it will draw attention away from the actual question. Re: the actual question, I have no clue. Sorry. I've never used custom allocators; they seem painful and useful only in rare circumstances. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Ian Collins <ian-news@hotmail.com>: May 12 08:43AM +1200 On 11/05/2020 22:44, Öö Tiib wrote: >> Write me a benchmark to prove your assumptions. > Why should I write you benchmarks when you post groundless > bullshit? Benchmarks written by me can't cure your stupidity. There be trolls... -- Ian. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 11 01:06PM -0700 On 5/11/2020 5:13 AM, Bonita Montero wrote: > > of its groundlessness ... nothing to argue there. > What I said isn't nonsense. > The "benefits" of adaptive locks have never been verified in practice. Do you think that an OS designer would add them in for no reason whatsoever? Most OS's use hybrid adaptive locking for their general purpose locks. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 10:29AM +0200 >> Try to really understand it. > Try to think yourself instead of shooting nonsense from hip. Write me a benchmark to prove your assumptions. |
| Bo Persson <bo@bo-persson.se>: May 10 04:44PM +0200 On 2020-05-10 at 13:49, Bonita Montero wrote: > 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. It could also be that the lock is held for a longer time, but not very often. Then it makes sense to make a quick check before doing a more expensive OS call. Bo Persson |
| 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. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 12:46PM +0200 > Why should I write you benchmarks when you post groundless > bullshit? You are not even able to argue against this "bullshit". > Benchmarks written by me can't cure your stupidity. You also aren't able to prove what you said. So it's you who has groundless assumptions. |
| 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. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 01:05PM +0200 >> in the situation where locks are only held a very short time. > But if the slow path is taken always, the locks are held for a long > time always. Doesn't change what I said. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 10 11:54PM -0700 On 5/10/2020 10:56 PM, Bonita Montero wrote: > Try to argue against that: if a lock is held a so small time that > spinning might succeed there's such a low likehood of a collision > that spinning isn't necessary. There are situations where a lock can get "hot", not matter what happens when the lock is held. Its held for a small amount of time, yet can experience periods of load. Trying to avoid slow-paths is a good thing. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 07:54AM +0200 > You said something like that if lock is needed very frequently for ^^^^^^^^^^^^^^^^^^^^^^^ ... > very short time then there is very low likelihood of collision. Try to really understand it. |
| 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. |
| "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 [...] |
| "Fred. Zwarts" <F.Zwarts@KVI.nl>: May 11 12:59PM +0200 Op 11.mei.2020 om 10:24 schreef Bonita Montero: >> first place? To avoid the slow-path! > But as I said the slow path is very unlikely to happen if you're > in the situation where locks are only held a very short time. But if the slow path is taken always, the locks are held for a long time always. -- Paradoxes in the relation between Creator and creature. <http://www.wirholt.nl/English>. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 11 01:48PM -0700 On 5/11/2020 1:43 PM, Ian Collins wrote: >> Why should I write you benchmarks when you post groundless >> bullshit? Benchmarks written by me can't cure your stupidity. > There be trolls... Are some trolls smarter than others? Is the size of the bridge or where its located? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 11 01:29PM -0700 On 5/10/2020 8:04 AM, Bonita Montero wrote: >> often. > Then spinning succeeds only when it is begun shortly before the other > thread releases the mutex, and that's very unlikely. You need to separate the work performed under the critical section, vs the usage pattern of the mutex. They are separate things. Even if the critical section is short, it can still be hammered by a bunch of threads for sustained periods of time. This will create contention. |
| 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