06:48:47 are haveno and seraphis out yet? (or when are they expect if not featured yet?) 06:48:58 s/expect/expected/ 06:54:31 See #haveno-dev if you want to help that one. I *think* the main seraphis github repo is https://github.com/UkoeHB/monero on a branch. 06:55:02 At least for seraphis, you still have a lot of time to help out. 12:10:33 Should be this branch https://github.com/UkoeHB/monero/tree/seraphis_lib 18:33:57 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()};` 18:36:06 I don't think what you wrote would guarantee ordered reads anyway. 18:36:46 what would be required to guarantee ordered reads then? 18:37:06 Looking :) 18:38:05 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) 18:40:13 1. according to `volatile` ( https://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 ( https://en.cppreference.com/w/c/language/eval_order ) "There is a sequence point after the evaluation of a full expression (an expression 18:40:13 that is not a subexpression: typically something that ends with a semicolon..." 18:40:32 Hrm. The thing I was thinking of only works for std::atomic. I don't suppose your refcounts are such ? 18:40:48 don't think so 18:41:02 What you said would work (I think) if the refcounts wre atomic, not what you save them to. 18:41:14 The writes should be ordered, but not the reads AFAIK. 18:41:30 You want a memory barrier to be blunt, but that seems to be C++20... 18:42:07 That seems like an odd requirement btw. 18:42:15 Are you sure you need it ? 18:43:54 yeah I have an idea for a safe pointer that has multithreaded value semantics... kind of hard to explain lol 18:45:08 Well, sorry then. I was thinking of atomic_load/atomic_store, doesn't apply. 18:46:37 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 18:47:22 GCC seems to have sync_synchronize, which is a memory barrier (blunt). 18:47:42 volatile just means "the value may change behind the back of the program". 18:47:56 Basically for I/O. 18:48:03 So don't assume things. 18:56:57 hmm ok, guess it's a harder problem than I expected 19:04:18 Well, if it's a test run, you can find a memory barrier for your OS/compiler. Like __sync_synchronize for GCC. 19:04:31 Blunt, but should do fine. 19:06:07 UkoeHB never use volatile for multi-thread synchronization, it's not designed for it 19:06:35 use std::atomic and std::memory_order 19:06:58 and std::atomic_thread_fence to guarantee memory ordering 19:06:59 That's for single thread IIUC. 19:08:12 Oh, nice, that looks like a C++11 memory barrier :D 19:08:36 sech1: ok thanks, reading up on the thread fence now 19:08:52 std::atomic_thread_fence will work fine even within single thread, compiler will not reorder memory accesses around it 19:10:10 memory_order_acq_rel should be enough 19:10:14 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)