Does the C# compiler reorder File-IO instructions?

Question

I have the following C# algorithm for config file writeback:

string strPathConfigFile = "C:\File.txt"
string strPathBackupFile = "C:\File.backup"
string strContent = "File Content Text";
bool oldFilePresent = File.Exists(strPathConfigFile);

// Step 1
if (oldFilePresent)
{
    File.Move(strPathConfigFile, strPathBackupFile);
}

// Step 2
using (FileStream f = new FileStream(strPath, FileMode.Create, FileAccess.ReadWrite, FileShare.None))
{
    using (StreamWriter s = new StreamWriter(f))
    {
        s.Write(strContent);
        s.Close();
    }
    f.Close();
}

// Step 3
if (oldFilePresent)
{
    DeleteFile(strPathBackupFile);
}

It works like this:

1. The original File.txt is renamed to File.backup.
2. The new File.txt is written.
3. File.backup is deleted.

This way, if there is a power blackout during the write operation, there is still an intact backup file present. The backup file is only deleted after the write operation is completed. The reading process can check if the backup file is present. If it is, the normal file is considered broken.

For this approach to work, it is crucial that the order of the 3 steps is strictly followed.

Now to my question: Is it possible that the C# compiler swaps step 2 and 3?

It might be a slight performance benefit, as Step 1 and 3 are wrapped in identical if-conditions, which could tempt the compiler to put them together. I suspect the compiler might do it, as Step 2 and 3 operate on completely different files. To a compiler who doesn't know the semantics of my exceptionally clever writeback procedure, Step 2 and 3 might seem unrelated.

Answer 1

According to the language specification , the C# compiler must preserve side effects when reordering statements. Writing to files is such a side effect.

Answer 2

In general, the compiler/jitter/CPU is free to reorder instructions as long as the result would be identical for a single thread. However, IO, system calls and most things involved with multi threading would involve memory barriers or other synchronization that prevents such reordering.

In the given example there is only a single thread involved. So if the File APIs are implemented correctly (and that would be a fairly safe assumption) there should be no risk of unintended behavior.

Reordering issues mostly popup when writing multi threaded code without being aware of all the potential hazards and requirements for synchronization. As long as you only use a single thread you should not need to care about potentials for reordering.