- lock-free single-producer/multi-consumer unbounded queue... - 18 Updates
- Still no inheritiance for enums? - 3 Updates
- One way to get strong exception guarantee for a multithreaded pop: a Dequeued_ class - 1 Update
- Fwiw, a thread-safe c++ deque example... - 1 Update
- The Lord calls out to you for repentance, salvation - 2 Updates
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 01:20PM -0700 On 3/21/2017 12:58 PM, Bonita Montero wrote: > a traditional mutex/condvar-duo is extremely low. So expecially for > producer-consumer-relationships, lockfree processing provides almost > no benefit over traditional locking. Fwiw, have you ever compared two identical queues wrt API, where one of them is lock-free, and the other is traditional single mutex lock? Put them under pressure, and see what one wins wrt the contrived tests. Track the work completed on a per worker thread basis. Run a lock-based queue for 10 minutes under stress load, and record the amount of work each thread has accomplished. Then run the same test using an efficient lock-free custom and compatible alternative, wrt API. And record its numbers. I all of my experience, a good lock-free version allows consumers threads to get more work completed in a stress filled environment. The mutex version will burn up under contention, loaded with calls to the kernel to block. Lock-free tries to avoid the kernel at all costs. Think of an adaptive mutex, does it not try to avoid the kernel by spinning? Keep in mind, there is a shi% load of total crap lock-free code on the net. Total race-infested garbage. Anyway, stressing out a sync algorithm is key, under load in unknown server request. Imvvho, at least. Fwiw, CAS was invented for this purpose, and is still in IBM principles of operation to this date. CAS is the initials of the guys name that invented it. Spin wait aside for a moment. There is a construct called an eventcount that works with basically any lock-free construct. Its like a condvar for these type of "exotic" sync algorithms. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 21 09:32PM +0100 Am 21.03.2017 um 21:20 schrieb Chris M. Thomasson: > Put them under pressure, and see what one wins wrt the contrived tests. There is no such pressure in real-wold apps because the interval producing or consuming an item is by magnitudes longer than the enqueuing- or dequeuing-interval. -- http://facebook.com/bonita.montero/ |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 01:39PM -0700 On 3/21/2017 1:32 PM, Bonita Montero wrote: > There is no such pressure in real-wold apps because the interval > producing or consuming an item is by magnitudes longer than the > enqueuing- or dequeuing-interval. Why does IBM keep patenting various non-blocking techniques? RCU? |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 21 09:43PM +0100 > Why does IBM keep patenting various non-blocking techniques? They're patenting lockfree algorithms for producer-consumer-relationships? > RCU? RCU is something completely different. -- http://facebook.com/bonita.montero/ |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 02:01PM -0700 On 3/21/2017 1:43 PM, Bonita Montero wrote: >> Why does IBM keep patenting various non-blocking techniques? > They're patenting lockfree algorithms for > producer-consumer-relationships? They have the CAS instruction to create these vary things, they have lock-free stack in principles of operation, to this date. RCU can be easily used for a very elaborate producer/consumer relationship. Basically, using RCU as a poor-mans targeted GC. Joe Seigh called it proxy garbage collection where: Reader threads are consumers of data Writer threads mutate the data. Yes, there are patents out there for producer/consumer relationship. Even communications based on multiplexing a bunch of single producer/consumer queues, with no atomic RMW ops can be helped by a RCU like device. Take a look at the SMR algorithm, and how its used for lock-free exception safe multi-producer consumer queues. Last I heard SMR was under patent application, from IBM. >> RCU? > RCU is something completely different. Not really, RCU is flexible. It is all about maximizing lock-free readers, this is hyper important aspect. The writer side can be mutexs, transnational memory, lock-free, wait free, flexible. The less intrusion the writer side has on the reader side of a RCU algorithm, the better. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 02:26PM -0700 On 3/21/2017 2:01 PM, Chris M. Thomasson wrote: >>> Why does IBM keep patenting various non-blocking techniques? >> They're patenting lockfree algorithms for >> producer-consumer-relationships? [...] Check this shi% out: https://www.google.com/patents/US8543743 ;^o |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 02:38PM -0700 On 3/21/2017 1:43 PM, Bonita Montero wrote: > producer-consumer-relationships? >> RCU? > RCU is something completely different. Check this out, from IBM, Joe is the sole inventor: https://www.google.com/patents/US5295262 I know he is extremely smart. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 02:46PM -0700 On 3/21/2017 2:26 PM, Chris M. Thomasson wrote: > Check this shi% out: > https://www.google.com/patents/US8543743 > ;^o Funny thing is that the following bounded queue beats this patented shi% to hell wrt performance: https://groups.google.com/d/topic/lock-free/acjQ3-89abE/discussion Yikes! |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 21 10:46PM +0100 Doesn't matter. The cases where lock-free consumer-producer-algorithms are beneficial over traditional locking are very rare because of the relationship I explained. -- http://facebook.com/bonita.montero/ |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 21 10:48PM +0100 > Funny thing is that the following bounded queue beats this patented shi% > to hell wrt performance: You also have the minimal experience with real-world programming like Aminer. -- http://facebook.com/bonita.montero/ |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 02:49PM -0700 On 3/21/2017 2:46 PM, Bonita Montero wrote: > Doesn't matter. The cases where lock-free consumer-producer-algorithms > are beneficial over traditional locking are very rare because of the > relationship I explained. Have you read the patent here? https://www.google.com/patents/US5295262 Its a strong thread safe reference counting mechanism. Are you saying that reference counting should probably be using mutexs? |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 21 10:52PM +0100 > Its a strong thread safe reference counting mechanism. Are you > saying that reference counting should probably be using mutexs? I was talking about producer-consumer-relationships and that there is almost no speedup in most real-world-code with lock-free producler -consumer algoritms. -- http://facebook.com/bonita.montero/ |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 02:55PM -0700 On 3/21/2017 2:52 PM, Bonita Montero wrote: > I was talking about producer-consumer-relationships and that there > is almost no speedup in most real-world-code with lock-free producler > -consumer algoritms. Even in audio apps? |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 21 10:56PM +0100 > Even in audio apps? ... for which you have never written any code. -- http://facebook.com/bonita.montero/ |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 02:58PM -0700 On 3/21/2017 2:56 PM, Bonita Montero wrote: >> Even in audio apps? > ... for which you have never written any code. Are you trolling me? I have had discussions with some people in the field. They are really into the single producer/consumer aspect, the less atomic RMW the better. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 02:59PM -0700 On 3/21/2017 2:48 PM, Bonita Montero wrote: >> to hell wrt performance: > You also have the minimal experience with real-world programming like > Aminer. Comparing me to Aminer's behavior is pretty damn harsh. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 21 11:00PM +0100 You seem very far from being a programmer like Animer. -- http://facebook.com/bonita.montero/ |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 21 11:02PM +0100 > Comparing me to Aminer's behavior is pretty damn harsh. The difference to to Aminer is only the posting-frequency. -- http://facebook.com/bonita.montero/ |
| Ian Collins <ian-news@hotmail.com>: Mar 22 09:36AM +1300 On 03/22/17 09:11 AM, Christopher Pisz wrote: > states. That would make for a lot of classes! I guess that comes from > a DDD mindset. > Thoughts on that? He would probably end up with the same amount of code, less the boilerplate to define the classes. It would get quite messy with states within states. Having to pass classes rather than states around would necessitate they be dynamically allocated which is probably normal on C# or Java but not so in C++. -- Ian |
| legalize+jeeves@mail.xmission.com (Richard): Mar 21 08:53PM [Please do not mail me a copy of your followup] Ian Collins <ian-news@hotmail.com> spake the secret code >He would probably end up with the same amount of code, less the >boilerplate to define the classes. It would get quite messy with states >within states. I think his point is that enums are sometimes used to implement "switch on enum" type behavior, which is really poor man's polymorphism so why not just use real polymorphism directly to express the part that invariant (base class) vs. the part that is changing (virtual method). There are plenty of legitimate uses of enums that don't fall into this category. I do see lots of poor man's polymorphism hiding in classes though. It tends to creep up on you. First you pass in a bool to toggle behavior, then it's a couple more bools. Then you realize that the distinct combinations of bools are used only in individual use cases and that they represent polymorphism, so the next time you need to add another "sometimes do it this way" flag, you refactor to polymorphic classes and the design becomes clearer and cleaner. Her's an example of poor man's polymorphism: <https://refactoring.guru/replace-conditional-with-polymorphism> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 21 10:33PM +0100 On 21-Mar-17 9:11 PM, Christopher Pisz wrote: > states. That would make for a lot of classes! I guess that comes from > a DDD mindset. > Thoughts on that? It sounds as if you were discussing using the enum to discriminate between different sets of functionality, different logical sub-types. In that case (but not in the case of just using the enum to e.g. report the current connection status) I'd agree with your friend. Essentially, with NF different functions, each of which might or might not apply in a given state, and each of which might be implemented differently in some states, and with NS different states, the main choice is between A) NF function implementations, each of which internally discriminates NS different states and do possibly different things in each state, or B) MS×NF function implementations, where each set of NF implementations is appropriate for and need consider only a given state. The total code size can be about the same, but the latter is more maintainable because (1) it /separates concerns/, and (2) it avoids the /type discrimination/, which is a common anti-pattern because the discrimination has to be updated in each of umpteen places in the code. In order to present (B) to client code as a simple set of only NF functions, one can use the envelope/letter idiom. As far as I know it was first named as such by Coplien. See <url: http://tinf2.vub.ac.be/~dvermeir/c++/EuroPLoP98.html#EnvelopeLetter> (the images are now lacking, they may have been archived by the Wayback Engine, possibly). For example, the Eiffel language lacks enum support because Bertrand Meyer wanted to discourage the common anti-pattern of discriminating on a type indicator value (having a value that specifies how to interpret the data) rather than using language-supported polymorphism such as the the virtual functions of the envelope/letter-idiom. The problem with the indicator of logical type is that, in general, proper maintenance becomes impossible as the system grows. For when a logical subtype is removed, or a new one is added, all places that do such discrimination must be updated, regardless of how well hidden and convoluted the discrimination is in each case (e.g. relying on an assumption about how state has been set earlier in code in a completely different source). In one very limited sense it's a case of redundancy gone amok, having that discrimination repeated all over the place, but it's worse because there can be e.g. logical subtype relationships that are leveraged in different ways in different places, yielding no simple pattern to recognize the various instances of discriminating code. On the third hand, each case is unique, just as each human is unique, and as each model of car is unique. "Oh it's a Ford, then it's prone to rusting" is invalid reasoning when one knows which particular Ford model this car is, or when one knows even more specifically that it's a 12 year old car with no rust so far. It's no good to go all overboard with patterns and classes every which way if /a much simpler/ and smaller solution is obtained with an enum (one case that springs to mind is a discriminated union for a compiler's token handling). ;-) Cheers!, - Alf |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 02:21PM -0700 On 3/20/2017 7:47 PM, Alf P. Steinbach wrote: > Dequeued_( Queue& q ) > : Dequeued_{ get_lock( q ), q.m_queue } > {}[...] Love this idea of the special class as an aid for a pop function, and how it only requires copy constructable, not assignment. I also like because I did not know that a move would not release the lock wrt the get_lock function, it hands off, or moves ownership of the mutex back to the caller. Thanks Alf. :^) |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 02:05PM -0700 On 3/21/2017 3:54 AM, Chris Vine wrote: > Yes, this is exactly what I was suggesting you should do. > There are variations on this theme. I would move into 'out': > out = std::move(m_queue.front()); Thank you. > assignment operator does not throw, otherwise it only gives the basic > guarantee. The basic guarantee gives you pretty much all you need for > many purposes, and is all you are going to get out of a lock free queue. Well, certain lock-free queues can be totally exception safe in the sense that the functions can be marked as nothrow. |
| legalize+jeeves@mail.xmission.com (Richard): Mar 21 08:22PM [Please do not mail me a copy of your followup] *PLONK* Another fucking idiot joins the others in my KILL file. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 21 01:35PM -0700 On Tuesday, March 21, 2017 at 4:22:18 PM UTC-4, Richard wrote: > *PLONK* > Another .. idiot joins the others in my KILL file. Oh Richard! You are traveling at highest speed into self-destruction. You are moving with reckless disregard for all cries of warning, of all attempts to grab your arm and get your attention. You are moving at breakneck speed toward a destination that will swallow you whole forever. What makes me weep is that it doesn't have to end that way for you! You can be saved, Richard! You have value and merit and there is the free gift of eternal life which you too can possess! Do you want to be destroyed at the end of your time here on Earth? Or do you want to live on and explore the wonders and riches of this enormous universe? And even more? The day is coming, Richard, such that unless you repent and ask Jesus to forgive your sin, things for you will change. At the end of your life on this world, your pride will not only catch up with you, but will run you over like a steamroller when you stand in God's court. It will rise up and take hold of you and be the total and complete end of you ... forever. Never again will this universe have the benefit of any of your input, no matter how grand or small ... forever. In short: you are hardening your heart to the point where your very existence in this universe will be utterly and completely ceased... where you will never partake of anything beneficial ever again, never yield forth knowledge or assistance or enjoy reward ever again. Unless you repent and ask Jesus to forgive your sin, Richard, you will be ended permanently. Is that what you want for your existence? To be utterly crushed in fullest Hellfire? Thank you, Rick C. Hodgin PS - Can someone please re-post that so Richard can read it? |
| 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