RE: Lockless file reading

[David Schwartz]

> On Thu, 2003-08-28 at 12:56, David Schwartz wrote:

> > > > You said that MD5 wasn't strong enough, and you would like
> > > > a guarantee.

> > > Yes. I don't really like it if my program heavily relies on something
> > > that can go wrong in some situations.

> > 	Okay, this is too much. Your alternative, assuming the kernel won't
> > re-order writes, is clearly relying on something that can go wrong.

> Reorder on per-byte basis? Per-page/block would still be acceptable.

	There is no law that says the kernel can't re-order on a per-byte basis.
Memory visibility and posted writes could, at least in theory, result in
this outcome today. Future technology may make it even more probable.

> Anyway, the alternative would be shared mmap()ed file. You can trust
> 32bit memory updates to be atomic, right?

	Yes, but you can't trust that multiple 32 bit memory updates won't be seen
out of order by another processor without appropriate barriers or
synchronization.

> Or what about: write("12"), fsync(), write("12")? Is it still possible
> for read() to return "1x1x"?

	I believe it still is. The 'fsync' function does not synchronize another
process' view of memory. It is not a memory barrier and, in any event, if it
was a memory barrier it would be running in the wrong place. The 'fsync'
function syncs the memory with stable storage, it does not synch (or at
least, it is not guaranteed to sync) with the memory view of another
process.

	Nothing stops speculative reads for the two halves of the data, each in
their own 32-bit unit, from crossing in time. Even if it's not possible on
today's hardware, it is still possible in principle.

	DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/