Is cross_beam epoch Atomic really atomic?

[ats1999]

Here is a question that i asked on stack overflow rust - Is crossbeam_epoch Atomic really atomic? - Stack Overflow
Is there anything wrong with this code?

[khimru]

@ats1999

Is there anything wrong with this code?

Nothing is wrong with the code, it works precisely like it should work. But not how you expect it to work.

@ats1999

I created 5 threads and in each threads incremented version of config by 1 for 100 times in a tight loop. I was expecting that at the completion of every thread, i'll get 500 as result.

IOW: you expected that Atomic pointer would work like Mutex, except faster and better… let me ask you a simple question: if Atomic can completely replace Mutex while ensuring that everything still works correctly… why would Mutex even exist?

@ats1999

I have a requirement to store a complex struct as config globally. Struct will be mostly read and seldom write.

That's precisely where atomic pointers are useful… but you have to understand what they could and couldn't do!

Atomic pointers don't guarantee the ability to change config willy-nilly. Nope.

What they provide is the ability to atomically switch from one data structure to another. And each thread would either see pointer to an “old” data structure and to a “new” one… but there are zero guarantees about content of these data structures, it's not protected in any way.

If different threads are allowed to touch these data structures concurrently – things become very strange. As you saw.

You would need another scheme which would guarantee that a “new” data structure is not modified when it's changing and al “old” data structure wouldn't disappear prematurely.

One trivial way that, nonetheless, can be usable in practice, if you don't change config “on the fly” that often is to just always create a new config when you need to change Atomic a repoint pointer to it while keeping all old configs around. Yes, it's a memory leak, but it could be acceptable if configuration is not changing often.

Or, if some tunables are adjusted regularly then split config in two parts and don't use Atomic pointers at all, but simple atomics for these things that should be changed regularly.

If you need to both change config and also keep number of allocated Configs bounded then you are entering RCU world which have many algorithms to deal with the need to know when all threads are, finally, done with old configs. Good luck exploding it (if you actually need it).