What is the insertion order if I have two memory-mapped buffers mapped to the same file?

Question

My question is whether the OS will respect the insertion order (i.e. last written, last to disk) or the order will be unpredictable. For example:

    byte[] s1 = "Testing1!".getBytes();
    byte[] s2 = "Testing2!".getBytes();
    byte[] s3 = "Testing3!".getBytes();

    RandomAccessFile raf = new RandomAccessFile("test.txt", "rw");
    FileChannel fc = raf.getChannel();
    MappedByteBuffer mbb1 = fc.map(MapMode.READ_WRITE, 0, 1024 * 1024);
    mbb1.put(s1);

    MappedByteBuffer mbb2 = fc.map(MapMode.READ_WRITE, mbb1.position(), 1024 * 1024);
    mbb2.put(s2);

    MappedByteBuffer mbb3 = fc.map(MapMode.READ_WRITE, mbb1.position() + mbb2.position(), 1024 * 1024);
    mbb3.put(s3);

    mbb1.put(s1); // overwrite mbb2
    mbb1.put(s1); // overwrite mbb3

    mbb1.force(); // go to file
    mbb3.force(); // can this ever overwrite mbb1 in the file?
    mbb2.force(); // can this ever overwrite mbb1 in the file?

Is it always last written, last in or am I missing something here?

Answer 1

I haven't tested any of this, so I don't know.

But, frankly, there's no guarantee on any of this ordering.

You have the mbb.force() method, but that's not the only way to write to the device, rather it just ensures that it has been written.

The VM can flush the page back to the device whenever it feels like it, using whatever schedule it deems fit, which is, naturally, extremely platform dependent (the behavior on Linux may be different than the behavior on Windows, it may even vary from Linux to Linux or Windows to Windows).

Seems to be that you should be coordinating internally to ensure that you only have one read/write buffer mapped to a specific area of a file, and manage the conflicts and overlap that way rather than relying on the operating system.

Edit: "changes done by multiple memory-mapped buffers are guaranteed to be consistent"

Simply, this means that the underlying VM, once a physical page is mapped in to a process, that mapping is shared across all of the assorted mappings performed. The thread issues is simply due to CPU memory cacheing and other issues.

So, this guarantees that all of the mappings will see the same data within an overlapping buffer. But it does not address when the buffers will actually get written to the device. Those points are still germane.

Overall it sounds like you won't have an issue if you handle any multithreading aspects correctly, and be aware that what you see in your underlying buffer may "change beneath your feet".