The problem is that the volatile function was given as a "functional barrier". Which it is on X86, but is not on an alpha. That was the point both of us were making. You do not want to use a solution that is architecturally sensitive and not know that. This was being suggested as a way to avoid the use of volatile, and I simply pointed out that it would only work on x86.Zach Wegner wrote:So what's the problem? Just add the fence instruction. Then you don't need volatile anymore.bob wrote:Our alpha is now officially retired and on the way to wherever retired machines go around here. But the barrier discussion was simply one case in point where something works fine on x86/x86-64 but fails miserably on another architecture like the alpha, where a real fence instruction needs to be added to that barrier function, the volatile trick is not good enough there.
And you can't just add the fence instruction, you still need a volatile keyword so that the compiler will not eliminate memory reads due to optimization, and fail to notice that a value has been changed by another thread. If you go the fence approach, you still need either the __volatile__ asm() option, or else volatile on the declarations for the variables that can be changed spontaneously. The fence just avoids the severe re-ordering for reads and writes that the alpha can do. And which one day I will bet X86 will do as well since it is currently a noticable bottleneck and is getting worse as processor speeds go up.