Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #120772
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: smrproxy v2 |
| Date | 2024-10-28 21:41 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <vfpp18$1dqvu$3@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);
> }
>
> 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
[...]
Humm... I am not sure if it would work with just the release. The
polling thread would read from these per thread epochs, _ref_epoch,
using an acquire barrier? Still. Not sure if that would work. Need to
put my thinking cap on. ;^)
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