On 13/01/15 17:54, [email protected] wrote: > 2015-01-13 13:50 GMT+03:00 Hallvard Breien Furuseth > <[email protected]>: >> comp.programming.threads's advise is that volatile is useless for thread >> sync: You need sync primitives, and then you don't need volatile since >> the compiler/hardware may not move the memory access past the primitive. > > Excuse me, but seems you are misunderstand comp.programming.threads in > case of blocking/locking multithreading and non-blocking > multithreading (aka lock-free/wait-free).
Yes, that didn't come out right. I don't mind inserting the volatile, but I don't know that it helps either. As far as I understand if it was broken without volatile, then it's still broken with it - just hopefully less likely to break. And LMDB couldn't be releaseed with your original unportable sync code along with the volatile. > (...) >> Unless the primitive's spec says so, I guess. E.g. with an "asm" >> statement where the compiler does not know what the assembly code does >> and must be told not to mess with ordering. > > Please study GCC's manual about __asm __volalile (:::"memory"), this > is just a "full compiler fence". Thanks, looks good. Will read the rest later. -- Hallvard
