- Interesting proposal... - 4 Updates
- anybody here? - 3 Updates
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 06 05:05PM -0800 Context: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0233r5.pdf SMR in std C++? Humm... |
| Lynn McGuire <lynnmcguire5@gmail.com>: Dec 07 12:04AM -0600 On 12/6/2023 7:05 PM, Chris M. Thomasson wrote: > Context: > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0233r5.pdf > SMR in std C++? Humm... "A hazard pointer is a single-writer multi-reader pointer that can be owned by at most one thread at any time. Only the owner of the hazard pointer can set its value, while any number of threads may read its value. A thread that is about to access dynamic objects optimistically acquires ownership of a set of hazard pointer (typically one or two for linked data structures) to protect such objects from being reclaimed. The owner thread sets the value of a hazard pointer to point to an object in order to indicate to concurrent threads — that may remove such object — that the object is not yet safe to reclaim." Looks cool. Are these currently supported in cpu hardware or would cpus have to be extended ? Lynn |
| Bonita Montero <Bonita.Montero@gmail.com>: Dec 07 07:57AM +0100 Am 07.12.2023 um 07:04 schrieb Lynn McGuire: > object in order to indicate to concurrent threads — that may remove such > object — that the object is not yet safe to reclaim." > Looks cool. ... The problem with that is: "The number of removed objects that are not yet reclaimed is bounded"; userland RCU ain't that flexible like kernel -RCU since you can't interact with the scheduler-code in userland so that you have a fixed number of hazard pointers. And hazard pointers how their superiority mostly in synthetic benchmarks; usually there's almost no gain over an atomic<shared_ptr<X>. |
| jseigh <jseigh_es00@xemaps.com>: Dec 07 05:52PM -0500 On 12/6/23 20:05, Chris M. Thomasson wrote: > Context: > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0233r5.pdf > SMR in std C++? Humm... It will be based on the one in Meta's folly library. Based on a quick scan of the code I think it will use a global membar if that is available. Looks like it will do some tracing collection for acyclic data structures. I (finally) got around to writing the proxy version of it here https://github.com/jseigh smrproxy - hazard pointer based proxy collector arcproxy - atomic reference counted proxy collector proxytest - timing tests atomic-ptr-plus - obsolete, not updated and missing some files during the sourceforge to google to github moves. Some timing comparisons in my blog here https://threadnought.wordpress.com/2023/06/09/smrproxy-timing-comparisons/ arcproxy looks good compared to rwlock but compared to smrproxy it looks really bad. The rcu timings are simulated. I've been considering creating an interface for all the different schemes. Not sure if it would be a c++ abstact class or a rust trait, neither are my main languages. But then I would need a shared data structure that would utilize it. I did figure out how to do a lock-free hashmap (w/ per bucket linked lists) that can do lock-free resizing but I found Cliff Click has one that's probably faster (because no linked lists). But all that's on back burner for now. Joe Seigh |
| Lynn McGuire <lynnmcguire5@gmail.com>: Dec 06 05:34PM -0600 On 12/5/2023 3:22 PM, Chris M. Thomasson wrote: > Humm. It seems as if this group has gone quite "dark" on my end. > Anybody there? ;^D Yup. Lynn |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 06 04:42PM -0800 On 12/6/2023 2:42 PM, Kaz Kylheku wrote: > that has gone into making it even more insanely bloated. > And that's nearly the only kind of user you're going to get > in a Usenet comp.* newsgroup. Well, I hope my activity here (partially wrt my "hyperactive" interactions with Bonita) did not chase people away to a point where they say, C++ can flush itself down a toilet filled with all sorts of crap! Fwiw, I am working on porting my xchg work system experiment from Relacy to pure C++11. I think it should be, on topic? Right? Or perhaps, should I offload it to my website and/or comp.programming.threads? |
| David Brown <david.brown@hesbynett.no>: Dec 07 08:23AM +0100 On 06/12/2023 21:44, Chris M. Thomasson wrote: > content, and let it be wrt the group. I think my experimental "work > system" is interesting because it only uses atomic exchange. No CAS, > XADD, ect... Also, its in pure C++11. I agree that there is a lot of interesting stuff buried there somewhere. But I don't think posting in a public group is the best way when it's still just ideas going around in your head. You need something a bit more concrete - either something new to show people, or questions to ask, in order to capture interest. "I'm thinking about this... or that... or maybe this..." doesn't make as good a thread. On the other side, big lumps of code are also not so good in threads as they are too much - I believe (and I'm extrapolating a lot here from myself, so I could be wildly wrong) that posts that are too big will simply be glossed over. Posting a link to a separate page/project/blog and adding a summary in the post will make it easier for those interested to study the matter when they have time. Discussion posts are viewed as too fleeting for that. But don't stop posting, whatever you do! >> that branch to stop boring everyone else. > For some reason this makes me think of both players moving their queens > back and forth, forevermore. The game goes nowhere... That's exactly the image I was going for! |
| 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