Path: ...!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: Mon, 16 Sep 2024 13:01:27 -0700
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <vca2qn$314se$2@dont-email.me>
References: <vc7ahq$2akr4$1@dont-email.me> <vc7f99$2atht$6@dont-email.me>
 <vc8hka$2mc93$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 16 Sep 2024 22:01:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0f36da695d9f6b2ce32e431416f90f90";
	logging-data="3183502"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/GLrzrXHPxz+/H17Pd1C0Ro1WSloMK/HM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:TU5t8VmZVLJ9C8HbBG/MKOShVSk=
In-Reply-To: <vc8hka$2mc93$1@dont-email.me>
Content-Language: en-US
Bytes: 3002

On 9/15/2024 11:01 PM, Paavo Helde wrote:
> On 15.09.2024 23:15, Chris M. Thomasson wrote:
>> On 9/15/2024 11:54 AM, Paavo Helde wrote:
>> [...]
>>> So, what do you think? Should I just use std::atomic<std::shared_ptr> 
>>> instead? Any other suggestions? Did I get the memory order parameters 
>>> right in compare_exchange_weak()?
>>
>> Keep in mind that you need to make sure that 
>> std::atomic<std::shared_ptr> is actually lock-free...
>>
>> Make sure to investigate is_always_lock_free on your various arch's:
>>
>> https://en.cppreference.com/w/cpp/atomic/atomic/is_always_lock_free
> 
> I already checked this, it is returning false at least on one of my 
> target platforms (Visual Studio 2022, Windows x86_64). IIRC Bonita 
> claimed this might be a false negative though.

I sure hope Bonita is right about that! Because it should be lock-free 
for many arch's. Damn it!... People rely on is_always_lock_free for 
certain things to be true about it, as in its result can be trusted. 
Bonita found that its actually always lock-free after all wrt libatomic, 
iirc. C/C++ should report this correctly. I have not investigated this 
for myself yet. Been really busy lately.


> Meanwhile I think I found a bug in my posted code, I should probably use 
> compare_exchange_strong() instead of compare_exchange_weak(). I somehow 
> thought the latter would err on the safe side, but it does not. In my 
> test harness there seems to be no difference.

Keep in mind that compare_exchange_weak can fail even though the 
comparands are the same. It can spuriously fail. compare_exchange_strong 
acts more like CMPXCHG on x86 vs a LL/SC on a PPC or something. 
Pessimistic vs optimistic... Also, make sure to pad and align things 
properly on cache line boundaries. Well, get it working first, then 
think about that... I still have not properly examined your code. Sorry! 
;^o Way busy.