Article <vfqgkc$1hfo1$1@dont-email.me>

Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <vfqgkc$1hfo1$1@dont-email.me>

Deutsch English Français Italiano

<vfqgkc$1hfo1$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: jseigh <jseigh_es00@xemaps.com>
Newsgroups: comp.lang.c++
Subject: Re: smrproxy v2
Date: Tue, 29 Oct 2024 07:23:56 -0400
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <vfqgkc$1hfo1$1@dont-email.me>
References: <vequrc$2o7qc$1@dont-email.me> <verr04$2stfq$1@dont-email.me>
 <verubk$2t9bs$1@dont-email.me> <ves78h$2ugvm$2@dont-email.me>
 <vetj1f$39iuv$1@dont-email.me> <vfh4dh$3bnuq$1@dont-email.me>
 <vfh7mg$3c2hs$1@dont-email.me> <vfm4iq$ill4$1@dont-email.me>
 <vfmesn$k6mn$1@dont-email.me> <vfmf21$kavl$1@dont-email.me>
 <vfmm9a$lob3$1@dont-email.me> <vfn2di$r8ca$1@dont-email.me>
 <vfntgb$vete$1@dont-email.me> <vfp1c3$16d9f$1@dont-email.me>
 <vfpd43$186t4$1@dont-email.me> <vfpomm$1dqvu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 29 Oct 2024 12:23:56 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ac8ee95b19a1901ed81555f68070b1d5";
	logging-data="1621761"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/QtCEvlgyIEOl28KARsqPF"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:NdxrNYrIJWSb6r10W/NWETh0Cog=
In-Reply-To: <vfpomm$1dqvu$1@dont-email.me>
Content-Language: en-US
Bytes: 2536

On 10/29/24 00:35, Chris M. Thomasson wrote:
> On 10/28/2024 6:17 PM, jseigh wrote:
>> On 10/28/24 17:57, Chris M. Thomasson wrote:
>>> On 10/28/2024 4:45 AM, jseigh wrote:

>>
>> fwiw, here's the lock and unlock logic from smrproxy rewrite
>>
>>      inline void lock()
>>      {
>>          epoch_t _epoch = shadow_epoch.load(std::memory_order_relaxed);
>>          _ref_epoch.store(_epoch, std::memory_order_relaxed);
> 
> 
>>          std::atomic_signal_fence(std::memory_order_acquire);
> ^^^^^^^^^^^^^^^^^^^^^^
> 
>>      }
> 
> Still don't know how your pure C++ write up can handle this without an 
> std::atomic_thread_fence(std::memory_order_acquire).

No thread fence is necessary.  The loads can move before
the store.  They just can't move before the async
membar.  After that membar any previously retired
objects are no longer reachable.

> 
>>
>>      inline void unlock()
>>      {
>>          _ref_epoch.store(0, std::memory_order_release);
>>      }
>