2015-01-13 13:50 GMT+03:00 Hallvard Breien Furuseth <[email protected]>: > On 01/12/2015 07:15 PM, [email protected] 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.
