are haveno and seraphis out yet? (or when are they expect if not featured yet?)

s/expect/expected/

See #haveno-dev if you want to help that one. I *think* the main seraphis github repo is github.com/UkoeHB/monero on a branch.

At least for seraphis, you still have a lot of time to help out.

Should be this branch github.com/UkoeHB/monero/tree/seraphis_lib

C/C++ question: I have two shared_ptrs and want to guarantee sequential reads of their use counts (no compiler reordering). Is it sufficient to do this (or perhaps overkill?)? `volatile const size_t count1{ptr1.use_count()}; volatile const size_t count2{ptr2.use_count()};`

I don't think what you wrote would guarantee ordered reads anyway.

what would be required to guarantee ordered reads then?

Looking :)

it just has to be ordered reads from a single thread (reading these counts is locked by a mutex, and incrementing/decrementing them is correctly ordered by constructor/destructor rules)

1. according to `volatile` ( en.cppreference.com/w/c/language/volatile ), "within a single thread of execution, a volatile access cannot be optimized out or reordered relative to another visible side effect that is separated by a sequence point from the volatile access." and then ( en.cppreference.com/w/c/language/eval_order ) "There is a sequence point after the evaluation of a full expression (an expression

that is not a subexpression: typically something that ends with a semicolon..."

Hrm. The thing I was thinking of only works for std::atomic<T>. I don't suppose your refcounts are such ?

don't think so

What you said would work (I think) if the refcounts wre atomic, not what you save them to.

The writes should be ordered, but not the reads AFAIK.

You want a memory barrier to be blunt, but that seems to be C++20...

That seems like an odd requirement btw.

Are you sure you need it ?

yeah I have an idea for a safe pointer that has multithreaded value semantics... kind of hard to explain lol

Well, sorry then. I was thinking of atomic_load/atomic_store, doesn't apply.

afaik all I need for it to work is that the use counts are guaranteed to be read in order, which seems to be what `volatile` achieves but I have never used that before

GCC seems to have sync_synchronize, which is a memory barrier (blunt).

volatile just means "the value may change behind the back of the program".

Basically for I/O.

So don't assume things.

hmm ok, guess it's a harder problem than I expected

Well, if it's a test run, you can find a memory barrier for your OS/compiler. Like __sync_synchronize for GCC.

Blunt, but should do fine.

UkoeHB never use volatile for multi-thread synchronization, it's not designed for it

use std::atomic and std::memory_order

and std::atomic_thread_fence to guarantee memory ordering

That's for single thread IIUC.

Oh, nice, that looks like a C++11 memory barrier :D

sech1: ok thanks, reading up on the thread fence now

std::atomic_thread_fence will work fine even within single thread, compiler will not reorder memory accesses around it

memory_order_acq_rel should be enough

I'm thinking I might need fenced atomic ref counters too, if there is a risk that incrementing/decrementing the shared ptr internal ref counts won't have guaranteed ordering (even if constructor/destructor calls have guaranteed order)