- std::atomic<std::shared_ptr<T>>... - 4 Updates
- Win32: WaitOnAddress vs. WaitForSingleObject - 3 Updates
- Google Groups (was Re: differential reference counting...) - 2 Updates
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 01 07:19PM +0100 Am 28.01.21 um 08:40 schrieb Chris M. Thomasson: > means that we can implement lock-free proxy collectors directly in the > C++20 standard using atomic shared_ptrs, without having to manually > create the reference counting logic. I think there can be no /generic/ solution. You basically need strong thread safety here. Usually this requirement needs an inner and an outer reference counter. There are slight variations of this pattern, but they are similar. At some point the outer reference count is transferred to the inner counter which requires to know /both/ data structures in one piece of code. std::atomic does not have this knowledge. However, one can write a partial specialization of std:atomic<shared_ptr<T>>) that implements the appropriate behavior. This /should/ be part of C++20. But there is no guarantee that this is implemented lock-free with an outer ref count. And obviously not all compilers already support this feature at all. :-/ Even worse, the signature of the deprecated atomic_... API functions prevents any efficient lock free implementation because the require shared instances of shared_ptr<T> to have exactly the same type than normal instances. Reasonable implementations need a different type for atomic instances. In fact shared instances cannot implement any operations provided by shared_ptr<T>. I implemented a lock free atomic version of a smart pointer several years ago. It was an intrusive pointer in my case, but this makes no significant difference. Unfortunately C++20 does not include std::atomic<std::intrusive_ptr<T>>. Most likely this is due to the restriction of std::intrusive_ptr that does only allows to modify the ref counter by one which prevents any efficient implementation. So at the end no custom atomic lock free implementation of std shared pointer can exist because it does not allow access to the reference counter. With some hacks a solution for intrusive_ptr might exist, it needs to transfer the outer ref count one by one. This could preferably done immediately after each modification of the outer count and after the object is really owned. But I think another hack is needed, because intrusive_ptr cannot deal with negative ref counts which require the object to be deleted at the increment operation. Marcel |
| "Öö Tiib" <ootiib@hot.ee>: Feb 01 12:57PM -0800 On Monday, 1 February 2021 at 20:20:19 UTC+2, Marcel Mueller wrote: > Most likely this is due to the restriction of std::intrusive_ptr that > does only allows to modify the ref counter by one which prevents any > efficient implementation. What is std::intrusive_ptr? I have read only one proposal of intrusive pointer to standard, it was named retain_ptr and AFAIK it has not been added to std. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 01 02:00PM -0800 On 2/1/2021 10:19 AM, Marcel Mueller wrote: >> manually create the reference counting logic. > I think there can be no /generic/ solution. You basically need strong > thread safety here. Yeah. I think your right. Well, it might be nice for C++ to perhaps create a new smart pointer based on Joe's atomic_ptr. But, then they would get into the realm of possibly violating some patents... Humm... > This /should/ be part of C++20. But there is no guarantee that this is > implemented lock-free with an outer ref count. And obviously not all > compilers already support this feature at all. :-/ iirc, Peter Dimov tried really hard to get shared_ptr to support strong thread safety, but failed to do so. > I implemented a lock free atomic version of a smart pointer several > years ago. It was an intrusive pointer in my case, but this makes no > significant difference. I think I remember you way back on comp.programming.threads. Do you have any code remaining for your intrusive algorihtm? It would be fun to code it up in Relacy to check for any possible issues, if any. It seems that C++ does not have std::intrusive_ptr. Iirc, it was in boost. I might be missing something. > So at the end no custom atomic lock free implementation of std shared > pointer can exist because it does not allow access to the reference > counter. Damn. Iirc, this is akin to what Peter was mentioning way back. Existing shared_ptr needs to be modified at the implementation level without breaking any existing use case. Perhaps, it might be better for C++20 to create a new smart pointer that has strong thread safety... If you do not need strong thread safety, use shared_ptr. If you do, use atomic_ptr. Sound Kosher? > object is really owned. But I think another hack is needed, because > intrusive_ptr cannot deal with negative ref counts which require the > object to be deleted at the increment operation. Have you taken a look at my experimental proxy collector code? Still, I don't think it can be used to make shared_ptr strongly thread safe. Well, perhaps it can, but it would have to be an internal mutation of an existing implementation f shared_ptr. Oh well... At least my proxy gc can allow for a poor mans RCU. Almost finished with an example use case in pure C++. It involves a lock-free stack that does not need an ABA counter and allows for node deletion. Also, threads can iterate the whole stack where they do not need to worry about any nodes being deleted under their feet. A thread can iterate the lock-free stack while writer threads are mutating it, even deleting nodes from it. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 01 02:01PM -0800 On 2/1/2021 12:57 PM, Öö Tiib wrote: > What is std::intrusive_ptr? I have read only one proposal of intrusive > pointer to standard, it was named retain_ptr and AFAIK it has not > been added to std. Imvho, intrusive reference counts are very useful. They can remove the need to create an external object to hold the count and a pointer to the object it protects. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 31 09:27PM -0800 On 1/17/2021 1:13 AM, Juha Nieminen wrote: >> #define tjoin pthread_join > To be fair, this might have more to do with trying to make code as short as > possible, rather that avoiding a particular prefix. ;^) Short in the sense of function names? pthread_mutex_lock, vs pml? ;^) > I think it's an interesting psychological phenomenon why so many beginner > programmers, and even not-so-beginner ones, always try to make code, > especially variable and function names, as short as possible. Indeed. > 'err' instead of 'error', and so on. > Although, POSIX (and the unix world in general) is full of this, so it's > perhaps not a great mystery where they have learned this kind of coding. ;^) |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 01 09:01AM +0100 > To be fair, this might have more to do with trying to make code > as short as possible, rather that avoiding a particular prefix. My intent was to make less noise in the code. And for most people this makes my code more readbale. You're trying to sell compulsiveness as reason. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Feb 01 09:23AM -0500 On 1/17/21 4:13 AM, Juha Nieminen wrote: ... > I think it's an interesting psychological phenomenon why so many beginner > programmers, and even not-so-beginner ones, always try to make code, > especially variable and function names, as short as possible. I actually had a good reason for that during my first class in computer programming. It was 1976, and an alumnus had donated a long-obsolete IBM 1620 to my high school, which was the only reason we had a programming class. It used punched cards, and came with a card punch, card sorter, and card reader. It's not easy to correct a punched card, and I'm a very poor typist when I can't backspace to correct my errors. Therefore, every correctly typed card was precious to me. If I typed a identifier wrong the first time I wrote it, that became the new "correct" identifier. I got into the habit of writing my code in such a way as to allow the reuse of cards between different programs, for instance by using generic identifiers. I quickly dropped all of those bad habits as soon as I got a chance to use a computer where programs were stored as editable files. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 31 03:40PM -0800 On Sunday, 31 January 2021 at 10:17:20 UTC+2, Jorgen Grahn wrote: > > touch google groupswith a ten-foot pole. > Also see <https://lwn.net/Articles/827233/>, which seems to be from > when comp.lang.lisp got the same treatment back in July. Perhaps Google AI dislikes posts of that BASTARDO NAZI PEDOPHILO ASSASSINO madman. Strange that it does not filter such easy to filter crap instead of blocking the newsgroups where no one looks at such nausea anyway. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 31 11:01PM -0500 On Sun, 31 Jan 2021 15:40:49 -0800 (PST) > ASSASSINO madman. Strange that it does not filter such easy to filter > crap instead of blocking the newsgroups where no one looks at such > nausea anyway. The world is changing. People are being taught unaware that there are others in control of their lives. They must bow to the state and businesses who will demand things of you or you can't buy or sell. The truth is, this is all a precursor to the coming mark of the beast system that will be in the 7-year tribulation. We're seeing the groundwork being laid down right now. I urge everyone to come to repentance in Jesus Christ. To ask forgiveness for your sin and escape the coming calamity on Earth. ----- Jesus is your creator. He made you and doesn't want to judge you for the things you've done which are sin in His judgment. Instead, He wants to forgive you. He wants to set you free from that judgment like it never even happened. We each have sin. That sin causes us to be facing a day of judgment before God. What Jesus does is take away our sin. He lived on the Earth 2,000 years ago for about 33.5 years. He was God in the flesh, in a literal body like ours feeling all we feel, emotions, tiredness, hunger, thirst, hearing music, singing, dancing, everything. But unlike us He never sinned. This allowed Him to take on the weight of sin for all who believe in Him, so that He would die with our sin and we would be released from it. Jesus came to save men's souls from death, and from being cast into the eternal lake of fire. He came here in love, and He reaches out in love and forgiveness no matter what you've done, or how far you've strayed. He loves you with His whole heart, and He calls out to you through men and women like me pointing you to Him, but He calls out to you first and truly from that inner voice, the still small voice on the inside that is His signature call. You know that voice. You know why He's calling out to you (because He loves you and doesn't want to judge you, but is longing with greatest longing to forgive you). Put your faith and trust in Jesus today and ask Him to forgive your sin. You'll feel the change the moment you do. You'll feel eternity alive before you, and your future being secure. In love and hope men and women like me post these messages so that men and women like you will hear them and be set free, just as we were from others who went before us calling out likewise. There is forgiveness at the cross of Christ. Real forgiveness. A fresh start. A new purpose in living. Peace. -- Rick C. Hodgin |
| 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