Lack of non-volatile "atomic_*" functions breaks some GCC4 apps

[waddlesplash]

Example: MUSCLE (BeShare's networking backend). This worked just file pre-scheduler merge, but now it won't compile due to the lack of non-volatile "atomic_*" functions.

I've heard that Paladin has the same problem; although I haven't looked into it yet.

(I'm on hrev47085.)

[pulkomandy]

We warned everyone: the GCC4 ABI is unstable and unsupported, and will change from time to time. Recompile the apps. If you don't want to hit these problems, use the GCC2 ABI and stick to whatever was available in BeOS.

This allows us to have a GCC4 ABI that's cleaned of legacy stuff.

[bonefish]

I don't think this is gcc 4 related. Pawel ​dropped the volatile qualifier from the parameter of the atomic_*() functions (I assume the summary and description are just the wrong way around). This breaks source compatibility (also for gcc 2), since code passing a volatile pointer to such a function will no longer compile.

While we haven't promised to maintain full source compatibility, in hindsight I cannot say what the reason for dropping the volatile qualifier was. It makes the requirement for the parameter stricter and AFAICT unnecessarily so. Maybe Pawel can shed some light on it.

[pdziepak]

That volatile qualifier was pointless. atomic_*() functions do not need it and it didn't help in any way when the variable has been accessed directly (usually, in such situation either volatile is not enough and a memory barrier is also needed or volatile is not needed at all). Moreover, in some use cases it is actually harmful, e.g. consider ​this file and how sNextHotVnodeIndex is used. That variable is accessed concurrently by many threads each holding read lock on sHotVnodesLock. It is also sometimes accessed with write lock on sHotVnodesLock and in such case neither atomic_*() functions are needed nor volatile qualifier.

In that commit I also broke binary interface of atomic_set() but as far as I know that particular function is Haiku addition. Unfortunately, it looks like atomic_{add, and, or}() have to stay the way they are now, which is very bad since they are much more expensive than it is often necessary.