- Regal eagle / American cloud - 13 Updates
- c++11: what's the guard variable for static local variable initialization? - 3 Updates
- Lock-free LRU-cache-algorithm - 5 Updates
- How all the cool kids are getting array lengths from C++11 onwards - 2 Updates
- Why I can't split a static library? - 1 Update
- Thread must sleep forever (Try to double-lock mutex?) - 1 Update
| Ian Collins <ian-news@hotmail.com>: Nov 02 12:43PM +1300 On 02/11/2019 10:20, Real Troll wrote: > why is everybody attacking a guy who is working on his C++ libraries > while religious nutters and Ramine posting his crap about Delphi and > Pascal!! Because he is a well proven religious bigot. -- Ian. |
| Daniel <danielaparker@gmail.com>: Nov 01 05:47PM -0700 On Friday, November 1, 2019 at 7:43:48 PM UTC-4, Ian Collins wrote: > On 02/11/2019 10:20, Real Troll wrote: > > why is everybody attacking a guy who is working on his C++ libraries Agreed. For what reason is it necessary to be so uncivil? > Because he is a well proven religious bigot. What is the point of making statements like this? Daniel |
| woodbrian77@gmail.com: Nov 01 07:07PM -0700 On Friday, November 1, 2019 at 6:43:48 PM UTC-5, Ian Collins wrote: > > while religious nutters and Ramine posting his crap about Delphi and > > Pascal!! > Because he is a well proven religious bigot. If you believe that G-d is G-d, some will try to label you this way. Maybe some will realize the envious environment I've been dealing with here. I feel a little like Joseph with his regal robe. The brothers treated their father and Joseph like !*%^, but G-d protected Joseph and brought his dreams to pass. Brian |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 02 10:21AM +0100 > why is everybody attacking a guy who is working on his C++ libraries > while religious nutters and Ramine posting his crap about Delphi and > Pascal!! The rule is not if the postings are on/off-topic or wether they're of any interest for anyone here. And woodbrain's rudiementary code are not of any use for anyone here. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 02 04:33PM > like Joseph with his regal robe. The brothers treated > their father and Joseph like !*%^, but G-d protected > Joseph and brought his dreams to pass. You have been labelled a religious bigot because you *are* a religious bigot. You are a homophobic, sexist misogynist which makes you a bigot and your bigotry is informed by your fucktarded beliefs in your fucktarded religion which makes you a religious bigot. Pretty simple math, huh, Bob? /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," Bryne 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." |
| woodbrian77@gmail.com: Nov 02 10:26AM -0700 On Friday, November 1, 2019 at 2:25:05 AM UTC-5, Bonita Montero wrote: > > Can you give me some suggestions on how to improve my > > repo: https://github.com/Ebenezer-group/onwards ? > Yes: delete it and stop posting here. Over the years the functionality of the repo has increased while the size of the repo has decreased. I don't recall if you have ever provided an idea that I've found useful, but a lot of people in the newsgroup have. On behalf of those people and myself, I press on. I encourage people to develop some closed source code also. Brian https://github.com/Ebenezer-group/onwards |
| Melzzzzz <Melzzzzz@zzzzz.com>: Nov 02 05:43PM > I encourage people to develop some closed source code also. Every code is closed, until open :P -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| woodbrian77@gmail.com: Nov 02 10:46AM -0700 On Saturday, November 2, 2019 at 11:33:43 AM UTC-5, Mr Flibble wrote: "In G-d we trust" has been on American money for centuries. Before our national motto was "In G-d we trust" it was "mind your own business". Sorry, but SaaS is important. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 02 06:52PM +0100 > if you have ever provided an idea that I've found useful, > but a lot of people in the newsgroup have. On behalf of > those people and myself, I press on. Do you have noticed anyone interested in yor work here? I didn't. |
| woodbrian77@gmail.com: Nov 02 11:11AM -0700 On Saturday, November 2, 2019 at 12:53:00 PM UTC-5, Bonita Montero wrote: > > those people and myself, I press on. > Do you have noticed anyone interested in yor work here? > I didn't. There have been scores of people that have replied to my posts where I've found the replies helpful. I don't know how interested they were in my work, but in my opinion their replies were useful. Also my replies to people are not always because I'm interested in their work. Brian Ebenezer Enterprises - "Brothers, I do not consider myself yet to have laid hold of it. But one thing I do: Forgetting what is behind and straining toward what is ahead, I press on toward the goal to win the prize of G-d's heavenly calling in Messiah Yeshua (aka Jesus)." Philippians 3:13,14 |
| David Brown <david.brown@hesbynett.no>: Nov 02 08:16PM +0100 > posts where I've found the replies helpful. I don't know > how interested they were in my work, but in my opinion > their replies were useful. I have never seen anyone express any interest in your work - but I've seen a lot of people suggest you are barking up the wrong tree with the whole idea. However, that is entirely up to you - if you believe in your software and business idea, go for it. But that does /not/ mean we want your spam here. When you ask concrete C++ questions, or discuss concrete C++ issues, then of course people will discuss it. And maybe some of these posts will help you - maybe they will help others. That does not mean anyone cares about your software at all. This is the /norm/. No one here cares about the software /I/ write. Few people care about any software than anyone else here writes. I don't care about Mr. Flibble's graphics library (though it is one of the few projects here where others might be interested in the software itself, rather than just the C++ discussions). I still wish him luck with it, and hope he achieves his goals - but if he ever asks a question and I give him a helpful answer, it's because I am interested in talking about C++, not because I want to help out his project. Does that make sense to you? So if you want to ask specific, concrete C++ questions, you'll get replies - probably helpful ones. If you ask for people to work on your project for you, you'll get nothing positive back. If you post spam, you'll get mostly insults in reply. If you post religious waffle, you'll get mockery. If you post bigotry and prejudice, you'll get condemnation. If you post absurd egoism and narcissism (like your claims of being the next Noah or Joseph, or God's appointed C++ guardian), you will be treated with a mixture of laughter, and pity for your madness. No one cares what you want to believe in - pink unicorns, ancient gods, or whatever. We don't want to know - its a personal matter for you alone. We /do/ care if you use those beliefs to justify hatred, prejudice, or if you try to spread them where nobody wants to hear them. Stick to specific C++ questions or comments, and if someone makes a reply you don't like, ignore it. And please stop digging yourself deeper into your hole. > Also my replies to people are not always because I'm > interested in their work. Of course. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 02 01:18PM -0700 On 11/2/2019 10:52 AM, Bonita Montero wrote: >> those people and myself, I press on. > Do you have noticed anyone interested in yor work here? > I didn't. Please, can you give a proper attribution? Almost begging. :^) |
| Melzzzzz <Melzzzzz@zzzzz.com>: Nov 02 08:37PM >> Do you have noticed anyone interested in yor work here? >> I didn't. > Please, can you give a proper attribution? Almost begging. :^) She is rude person... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 27 12:44AM +0100 On Sun, 27 Oct 2019 00:24:15 +0100 > semantics and so forces an ordering, even in a case where a race has > occurred with respect to the original check of initializerHasRun() > outside the mutex. Actually on looking further at the code it does seem to suffer from the traditional double checked locking problem in that a second thread could assume initialization by the first thread before it has in fact occurred. Presumably either there is something else which deals with that problem or the compiler, knowing its platform (which is presumably x86/64 in this case), has calculated that this cannot in practice occur with its total store ordering memory model. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 26 08:55AM +0200 > https://godbolt.org/z/yRtxL_ > I searched over the internet, only some materials discussed that the guard variable is 64 bit and the LSB should set when initialization is done. > I am new to c++, forgive me if I am asking silly question. The (outer) guard variable doesn't need to be atomic because the worst that can happen in the case where it doesn't correctly reflect that initialization has been performed, is that the code goes into needless mutex locking and deeper checking, which is just an efficiency concern. However, this can only happen the first few times. Using an atomic (outer) guard variable would avoid needless rounds of mutex locking, but accessing that variable can be slower and would then be a cost incurred on every access of the static. Evidently the gcc devs decided to not do that. I.e., they /support/ the maximal efficiency for a general solution, without guaranteeing it, because it can't be guaranteed against all kinds of user code. For most calls, in practice all calls after the first, the overhead is then exactly the same as before C++ got thread support, the C++03 era, namely a simple checking of an ordinary non-atomic boolean flag. One way to ensure that in user code is to call the function from the main thread, before it can possibly be called from other threads. - Alf |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 27 12:24AM +0100 On Sat, 26 Oct 2019 15:43:35 -0700 (PDT) > so can I understand it like this?: > 1. the obj_guard get set in __cxa_guard_release(&obj_guard), this MUST (WHY?) happen after the initialize_the_object(). If not then we are facing the same problem in double-checking-lock: one thread holds the lock, and reorder the initialization and guard assignment, makes another thread waiting on line 1 incorrectly returns too eariler. > 2.after the obj_guard has been set, even another thread can't immediately see this update, it just go inside the needless lock/unlock, and this only happens the first few times. If you look at the code you will see that __cxa_guard_acquire() checks initializerHasRun() again after it has acquired the mutex. So all is fine - locking and then unlocking a mutex has acquire and release semantics and so forces an ordering, even in a case where a race has occurred with respect to the original check of initializerHasRun() outside the mutex. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 26 10:02AM +0200 >> recent block would be more efficient. > A brain has to be rather calcified to receive total damage from > simple idea how to get rid of constant race over top of list. Then tell me that simple idea no one published before. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 26 08:39AM +0200 And ... ... updates to the links are not always kernel-contention-free, but mostly, in my case it's configurable how often the updates will block. Look at this graph: https://abload.de/image.php?img=perfq9kri.png The bar-groups are the number of threads and within the group you can see the increasing parameter which controls how often kernel-contention happens from left to right. The leftmost blue bar in each group shows a zero-parameter where my algorithm blocks on every access and almost behaves like having a standard-mutex. My idea could also be applied to a completely different eviction -scheme like adaptive-replacement cache (https://bit.ly/2Pm2n1A). |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 25 09:35PM -0700 On 10/24/2019 11:20 PM, Bonita Montero wrote: > Yes, I pin entries in the LRU-list with a CAS so that they can't be > evicted. But that has nothing to do with the parallel updates of the > LRU-list. Okay. > So I describe it another time to give you a chance to guess how my > idea works: ;^) cache-hits cann occur paralell, i.e. the updating of the > LRU-list or flushed from it the LRU-list is exclusively locked. But > this doesn't hurt since I/O is usually slow in comparison to a cache > hit. Fast the path the hell out of it! Let me think here. Well, I wish I had more time, however, this is fun indeed. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 26 12:55AM -0700 On 8/10/2019 9:40 AM, Öö Tiib wrote: >> recent block would be more efficient. > A brain has to be rather calcified to receive total damage from > simple idea how to get rid of constant race over top of list. Indeed the head is lock-free! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 25 09:37PM -0700 On 10/25/2019 9:35 PM, Chris M. Thomasson wrote: >> hit. > Fast the path the hell out of it! Let me think here. Well, I wish I had > more time, however, this is fun indeed. A speedy lock-free deque, double linked list. A nice hash. Can be done. Fall back to locks, no problem indeed! This brings back many memories. Thanks Bonita. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 25 03:38PM On Thu, 2019-10-24, David Brown wrote: ... > (My money is still on the fishing term - it fits the usage very > accurately, and is confirmed by people who have used Usenet pretty much > since its conception.) The fishing term, boosted by the mythological creatures. I bet a less catchy (pun unintended) fishing term wouldn't have become so popular. > Rather than argue further, I recommend you take a couple of hours break > from Usenet and watch this film. It is time well spent! > <https://en.wikipedia.org/wiki/Trollhunter> Haven't seen it, but this one is nice, after a fashion: https://en.wikipedia.org/wiki/Border_(2018_Swedish_film) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| David Brown <david.brown@hesbynett.no>: Oct 26 05:21PM +0200 On 25/10/2019 17:38, Jorgen Grahn wrote: >> <https://en.wikipedia.org/wiki/Trollhunter> > Haven't seen it, but this one is nice, after a fashion: > https://en.wikipedia.org/wiki/Border_(2018_Swedish_film) I missed that one when it was on at the cinemas, but I plan to see it sometime. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 28 07:17AM >> went to commit the changes to a repository, but the commit failed >> because the ".a" file was too big. > So don't do that. There's seldom a need to commit generated files to SCM. It might not be generated code. Sometimes third-party libraries (especially closed-source, or semi-closed-source ones) may be distributed in binary form. Or sometimes the static library may indeed be built from the project files themselves, but this might take a very long time (like hours), and it might be convenient for other members of a project not to have to do that. Of course there are alternatives even in the first case (other than just putting instructions that tell other team members where to download the library and how to install it in the project directories), for example by using some kind of build script that automatically downloads the library and puts it in the proper place. But it can become complicated. |
| scott@slp53.sl.home (Scott Lurndal): Oct 25 04:22PM >>> for (;;) pause(); >> raise(SIGSTOP); >The exec() solution has one more benefit: it frees up virtual memory. Although the only overhead associated with virtual memory is the page tables. The OS can always reclaim the physical memory by swapping out dirty pages and replacing clean pages owned by the SIGSTOP'd process. |
| 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