Ion Gaztañaga schrieb:
Markus Schöpflin escribió:
So it's not an issue of memory barriers, but of a hardware not being able to serialize concurrent r/w access to the same location (either register or memory address)?
Yes. With 32 bits there is no problem for current architectures, but imagine we have a library for atomic 64 bit integers. Raw read and write would not be atomic in 32 architectures because memory read/write would be implemented with two memory accesses. We must also make sure that cache and other issues maintain the atomicity.
OK, I think I understand now. Thank you and thanks to Daniel, who has been answering me in private mail. I'll try to figure out whether Alpha hardware has this kind of atomicity build-in or whether it needs some special instructions for it. Another question: the atomic compare and swap operation as described in the header file returns the old value of the memory location. CXX provides CAS as a primitive, but it doesn't return the old value, it simply returns true/false if the CAS has succeeded/failed. I have checked the usage of CAS in the interprocess library, and it looks like you don't actually need the return value of the CAS function, besides checking that the operation has succeeded. Am I right? Would you consider changing the interface for CAS to allow the usage of a compiler primitive which doesn't provide the value of the memory location?
I'm not an atomic operation expert (even not a beginner). Functions were inspired by apache portable runtime atomics, and there atomic read and writes were wrapped. I just followed the example because I know that 32bit operations were atomic in Intel32 but I also know that there are systems (surely as used as Intel) that have not this property.
The header still contains the Apache license, I'm wondering if you simply can dual license it like you did? And isn't there a requirement that only boost licensed libraries are OK? Thank you for your help, Markus