Re: smrproxy v2

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.