Re: smrproxy v2

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

On 10/29/24 00:38, 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);
     }
>
     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

>
Only your single polling thread can mutate the shadow_epoch, right?
>

 Yes.  It's just an optimization. The reader threads could read
from the global epoch but it would be in a separate cache line
and be an extra dependent load.  So one dependent load and
same cache line.

Are you taking advantage of the fancy alignment capabilities of C++?
https://en.cppreference.com/w/cpp/language/alignas
and friends? They seem to work fine wrt the last time I checked them.
It's nice to have a standard way to pad and align on cache line boundaries. :^)