Are locks sequentially consistent?

Question

This is a C# version of this question: Is std::mutex sequentially consistent?

In short: if multiple threads take locks on different objects, are they guaranteed to see the same order of events within those different locks?

Here is the demonstration:

internal sealed class Test
{
    private readonly object lockerA = new object();
    private bool valueA;

    private readonly object lockerB = new object();
    private bool valueB;

    public void RunTest()
    {
        var taskA = Task.Run(() =>
        {
            lock (lockerA)
                valueA = true;
        });
        var taskB = Task.Run(() =>
        {
            lock (lockerB)
                valueB = true;
        });
        var taskC = Task.Run(() =>
        {
            // Reads A, then B.
            bool readA;
            lock (lockerA)
                readA = valueA;

            bool readB;
            lock (lockerB)
                readB = valueB;

            return (readA, readB);
        });
        var taskD = Task.Run(() =>
        {
            // Reads B, then A.
            bool readB;
            lock (lockerB)
                readB = valueB;

            bool readA;
            lock (lockerA)
                readA = valueA;

            return (readA, readB);
        });

        Task.WaitAll(taskA, taskB, taskC, taskD);

        if (taskC.Result == (readA:true, readB:false) && taskD.Result == (readA:false, readB:true))
        {
            // Can this happen?
            Console.WriteLine("Ordering inconsistency!");
        }
    }
}

EDIT:

Fixed an error after Matthew Watson showed that the example fails even with sequential consistency.

Answer 1

Locks do not guarantee sequential consistency. Rather, it guarantees that if a thread starts an operation where it requires a set of resources, no other thread can access (and alter) those resources till the thread with the lock is done with the resources. Which thread attempts to access the resources first is subject to a whole bunch of other factors which the lock doesn't really care about.

Use locks in operations where u want guarantee that an object(s) is not modified by other threads during that operations. Which operation accesses the thread first - thats a whole different story.

See the lock statement documentation.

Answer 2

To see if this could theoretically return (false, true) and (true, false) we just need to show a set of interleaved steps the tasks could theoretically perform with that result.

Here is such a set of steps:

Init: A = false, B = false

Task A: starting up
Task B: starting up
Task C: enter lock A
Task C: read A = false   C.A = false
Task C: leave lock A
Task A: enter lock A
Task A: set A = true     A = true
Task A: leave lock A
Task A: exit
Task D: enter lock B
Task D: read B = false   D.B = false
Task D: leave lock B
Task B: enter lock B
Task B: set B = true     B = true
Task B: leave lock B
Task B: exit
Task C: enter lock B
Task C: read B = true    C.B = true
Task C: leave lock B
Task C: exit returning (false, true)
Task D: enter lock A
Task D: read A = true    D.A = true
Task D: leave lock A
Task D: exit returning (true, false)

Now task C returned (false, true) and task D returned (true, false)

That proves that theoretically an out of sequence result could be returned.