Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.

[leo@yuriev.ru]

2015-01-13 13:50 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>:
> On 01/12/2015 07:15 PM, leo@yuriev.ru wrote:
>>
>> Unfortunately IMDB programmed without accounting possibility of memory
>> reordering and cache incoherency (as a proof - the 'volatile' was
>> missed before ITS#7969).
>> So, currently seems LMDB is durable only on x86 and may be on MIPS.
>
>
> I gather "volatile" in thread code can be read as "warning: dubious
> code" or at best "please access this sooner rather than later".
>
> 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, `volatile` don't needed, when a locking (e.g. mutex) is used for
access to any variables that shared between threads.

But LMDB don't uses locking primitives for interaction between writers
and readers.
LMDB properties declared as:
- readers don't block writers and writers don't block readers;
- read transactions are extremely cheap, and can be performed using no
mallocs or any other _blocking_ calls;

THEREFORE 'volatile' and memory-ordering ISSUES MUST BE HANDLED VERY
CAREFULLY AND ANXIOUSLY.

> 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".

> The best fix is likely a format change which reduces the need for sync
> primitives, for LDMBv2.  Checksum the MDB_meta, and/or replace the
> variable part with a single word which refers to the meta.
> Don't know if we can get rid of unportable sync code though.
Yes it is possible, but requires C++, see
http://en.cppreference.com/w/cpp/atomic/memory_order
By using just C, include C99 - not possible, see
http://stackoverflow.com/questions/27301371/memory-order-consistency-model-and-c99

> Leaving the rest to Howard, I'm too busy just now to do more than blow
> hot air:-)

Ok ;)

I created gist for public review, please share it.
https://gist.github.com/leo-yuriev/ba186a6bf5cf3a27bae7

Leonid.