Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #120770
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: smrproxy v2 |
| Date | 2024-10-28 21:35 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <vfpomm$1dqvu$1@dont-email.me> (permalink) |
| References | (10 earlier) <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> |
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:
>>> On 10/28/24 00:02, Chris M. Thomasson wrote:
>>>> On 10/27/2024 5:35 PM, jseigh wrote:
>>>>> On 10/27/24 18:32, Chris M. Thomasson wrote:
>>>
>>>>>
>>>>> The membar version? That's a store/load membar so it is expensive.
>>>>
>>>> I was wondering in your c++ version if you had to use any seq_cst
>>>> barriers. I think acquire/release should be good enough. Now, when I
>>>> say C++, I mean pure C++, no calls to FlushProcessWriteBuffers and
>>>> things like that.
>>>>
>>>> I take it that your pure C++ version has no atomic RMW, right? Just
>>>> loads and stores?
>>>
>>> While a lock action has acquire memory order semantics, if the
>>> implementation has internal stores, you have to those stores
>>> are complete before any access from the critical section.
>>> So you may need a store/load memory barrier.
>>
>> Wrt acquiring a lock the only class of mutex logic that comes to mind
>> that requires an explicit storeload style membar is Petersons, and
>> some others along those lines, so to speak. This is for the store and
>> load version. Now, RMW on x86 basically implies a StoreLoad wrt the
>> LOCK prefix, XCHG aside for it has an implied LOCK prefix. For
>> instance the original SMR algo requires a storeload as is on x86/x64.
>> MFENCE or LOCK prefix.
>>
>> Fwiw, my experimental pure C++ proxy works fine with XADD, or atomic
>> fetch-add. It needs an explicit membars (no #StoreLoad) on SPARC in
>> RMO mode. On x86, the LOCK prefix handles that wrt the RMW's
>> themselves. This is a lot different than using stores and loads. The
>> original SMR and Peterson's algo needs that "store followed by a load
>> to a different location" action to hold true, aka, storeload...
>>
>> Now, I don't think that a data-dependant load can act like a
>> storeload. I thought that they act sort of like an acquire, aka
>> #LoadStore | #LoadLoad wrt SPARC. SPARC in RMO mode honors data-
>> dependencies. Now, the DEC Alpha is a different story... ;^)
>>
>
> 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).
>
> inline void unlock()
> {
> _ref_epoch.store(0, std::memory_order_release);
> }
>
> epoch_t is interesting. It's uint64_t but handles wrapped
> compares, ie. for an epoch_t x1 and uint64_t n
>
> x1 < (x1 + n)
>
> for any value of x1 and any value of n from 0 to 2**63;
> eg.
> 0xfffffffffffffff0 < 0x0000000000000001
For some reason it reminds me of your atomic 63 bit counter from a while
back. If your smr_poll thread is the only thread that can increment the
epoch, then it will be able to detect rolling to zero, right? For one of
my older proxys the thread would have two version counters:
per_thread
{
word m_ver[2];
lock()
{
word ver = g_version;
m_ver[ver % 2] = ver;
}
unlock(word ver)
{
m_ver[ver % 2] = 0;
}
}
So, it's different logic. The only way I got around using memory
barriers (compiler barriers aside for a moment), here was for the
polling thread to use an asymmetric membar. For a pure C++ version, I
think it would require:
per_thread
{
word m_ver[2];
lock()
{
word ver = g_version;
m_ver[ver % 2] = ver;
#LoadStore | #LoadLoad;
}
unlock(word ver)
{
#LoadStore | #StoreStore;
m_ver[ver % 2] = 0;
}
}
I think.... Humm...
>
>
> The rewrite is almost complete except for some thread_local
> stuff. I think I might break off there. Most of the
> additional work is writing the test code. I'm considering
> rewriting it in Rust.
>
> Joe Seigh
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-17 08:10 -0400
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-17 13:10 -0700
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-17 17:08 -0400
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-17 16:40 -0700
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-17 17:16 -0700
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-17 17:24 -0700
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-18 08:07 -0400
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-25 15:00 -0700
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-25 18:56 -0400
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 12:33 -0700
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-27 18:29 -0400
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 15:32 -0700
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-27 20:35 -0400
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 21:02 -0700
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-28 07:45 -0400
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-28 14:57 -0700
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-28 15:09 -0700
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-28 21:17 -0400
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-28 21:35 -0700
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-29 07:23 -0400
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 14:51 -0700
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-28 21:38 -0700
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-29 07:27 -0400
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 14:56 -0700
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-30 12:36 -0400
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-01 12:20 -0700
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-28 21:41 -0700
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 15:05 -0700
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-30 12:39 -0400
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-03 21:14 -0800
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-04 07:46 -0500
Re: smrproxy v2 Muttley@DastartdlyHQ.org - 2024-11-04 14:09 +0000
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-04 12:42 -0800
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-09 13:51 -0800
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-12 00:43 -0800
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-12-12 07:29 -0500
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-12 13:55 -0800
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-12-12 19:48 -0500
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-25 20:36 -0800
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 21:08 -0700
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 21:09 -0700
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 21:13 -0700
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-28 22:02 -0700
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 23:40 -0700
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 23:42 -0700
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 23:53 -0700
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-29 23:54 -0700
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-10-30 12:43 -0400
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-02 13:50 -0700
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-21 15:17 -0500
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-23 11:10 -0500
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-23 13:31 -0800
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-23 17:12 -0500
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-23 17:46 -0800
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-24 15:14 -0500
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-24 15:19 -0800
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-24 19:09 -0500
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-24 16:37 -0800
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-24 16:48 -0800
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-24 16:47 -0800
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-25 06:31 -0500
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-25 14:12 -0800
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-11-27 10:29 -0500
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-12-09 13:34 -0500
Re: smrproxy v2 jseigh <jseigh_es00@xemaps.com> - 2024-12-11 07:13 -0500
Re: smrproxy v2 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-11 16:22 -0800
csiph-web