[Date Prev][Date Next]
Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
- From: email@example.com
- Date: Tue, 13 Jan 2015 16:54:05 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
2015-01-13 13:50 GMT+03:00 Hallvard Breien Furuseth <firstname.lastname@example.org>:
> On 01/12/2015 07:15 PM, email@example.com 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
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
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:-)
I created gist for public review, please share it.