[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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

> 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
By using just C, include C99 - not possible, see

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