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

[leo@yuriev.ru]

2015-01-14 8:49 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>:
> On 13/01/15 19:23, Hallvard Breien Furuseth wrote:
>>
>> 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.
>
>
> Sorry, nevermind.  Of course when the writer does sync well enough,
> volatile + the txn_renew loop will have to do for a sync primitive in
> the reader.

> I suppose this requires that sync in the writer thread
> will shake other threads as well, it won't be private to the writer.

In general this is wrong, more precisely depend on 'volatile' on
shared variables and usage of barriers/fences by the readers.

Sync-ops due lock/release a mutex by writer issue a memory-barrier for
its own thread.
With this compiler must update all modified variables, which shaded in
the CPU registers.
Next a hardware write-barrier (aka release) in the mutex-release code
enforce all changes to be visible for other threads (e.g. flush the
cache).
But 'be visible' here mean 'publish' and other threads can access
these changes, but if want this.

In general, to see changes made by the writer, all other threads
should issue a read-barrier (aka acquire).
On most arches such barrier just inform compiler that memory was
changed and variables which cached in the registers must be reloaded.
But in some cases (like Itanium) this barrier will be taken in account
for instruction scheduling.
For 'volatile' compiler should generate barriers each time on read or
write such variables.

More general, memory-barriers are very important to HPC, distributed
computing and for super-computers.
For example read-barriers may pull changes from internode-bus or other
nodes, and write-barriers - publish the local changes.

So, the one way to avoid a race bugs - thinking in terms of
publish/pull changes.