Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: Atomic caching of smart pointers
Date: Sun, 29 Sep 2024 13:37:58 -0700
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <vdcdr7$1seik$1@dont-email.me>
References: <vc7ahq$2akr4$1@dont-email.me> <vc7f5o$2atht$5@dont-email.me>
 <vca82m$32puo$1@dont-email.me> <vca8v5$327mo$1@dont-email.me>
 <vcb5ij$3c3g5$1@dont-email.me> <vcb5r9$3c740$1@dont-email.me>
 <vcb65v$3c73m$1@dont-email.me> <vcbhoq$3epub$1@dont-email.me>
 <vd2sln$2lkc$1@dont-email.me> <vd3c5a$4sp5$1@dont-email.me>
 <vd4u0o$dv0m$1@dont-email.me> <vd8a4u$159kt$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 29 Sep 2024 22:37:59 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="16cc1ba594f277a64d75fbbaac003767";
	logging-data="1981012"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX193QrDVJUM/bGE5CgEk7FzVryRDono9/is="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:sZeW0aG3J5d/W1GkFinnk6bspDw=
In-Reply-To: <vd8a4u$159kt$1@dont-email.me>
Content-Language: en-US
Bytes: 3032

On 9/28/2024 12:10 AM, Paavo Helde wrote:
>> On 27.09.2024 03:24, Chris M. Thomasson wrote:
[...]
>>
>> Sorry for all the questions. ;^o

> No-no! I'm happy to think over this code.
> 
> I'm still a bit worried about the memory order parameteres, I have not 
> used them before and I suspect they might not be distinguishable on the 
> platforms which I need to support (x86_64 and ARM64, MSVC++ and g++), so 
> I might not understand if they are wrong. Maybe I should just use the 
> default memory_order_seq_cst if it does not make any difference anyway 
> on these platforms?

Well, using memory_order_seq_cst is okay just to make sure the algorithm 
is working, or if the algo needs it to begin with. Then, we can think 
about fine tuning it down to its bare minimum. Actually, you made me 
think about the membars wrt basic thread saftey refcounts.

I think if a reference drops to zero, the thread that accomplished that 
event needs to perform an acquire membar before doing anything with it. 
It's hard to remember for me right now. It's coming back, but I am 
really busy right now, sorry. Humm...

pseudo code, typed in the newsreader, sorry for any typos:
___________________
void refcount_dec(refcount& p)
{
     // decrement the count.
     if (p.m_refs.fetch_add(-1, std::memory_order_release) == 1)
     {
         // 1 + (-1) = 0
         // drop to zero condition detected!

         // iirc, this needs to be here...
         std::atomic_thread_fence(std::memory_order_acquire);

         // okay, we are fine.
         // We are the only thread that can see it right now.
     }
}
___________________