[Date Prev][Date Next]
Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
On 13/01/15 17:54, email@example.com wrote:
> 2015-01-13 13:50 GMT+03:00 Hallvard Breien Furuseth <firstname.lastname@example.org>:
>> 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.