Re: smrproxy v2

On 10/29/2024 4:23 AM, jseigh wrote:

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.

Ahhhh. I thought your C++ version is going to be one that did not use an asymmetric membar in order to make it so called "100%" pure... Not sure about C++ including one in the actual standard. If they did I think it would have some info about it, perhaps akin to:
https://en.cppreference.com/w/cpp/atomic/atomic/is_lock_free
Well, even then if an asymmetric was not available on the arch the code is being compiled for, it can say, well, shit happens! Then allow you to fall back to another version...?
Also, the C++ wording of this is interesting:
https://en.cppreference.com/w/cpp/atomic/atomic/is_always_lock_free
wrt:
_____________
​0​ for the built-in atomic types that are never lock-free,
1 for the built-in atomic types that are sometimes lock-free,
2 for the built-in atomic types that are always lock-free.
_____________
That's fun... ;^)

 

>

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

>