On 13/01/15 17:54, leo@yuriev.ru wrote:
2015-01-13 13:50 GMT+03:00 Hallvard Breien Furuseth h.b.furuseth@usit.uio.no:
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.