Does lock() guarantee acquired in order requested?

IIRC, it's highly likely to be in that order, but it's not guaranteed. I believe there are at least theoretically cases where a thread will be woken spuriously, note that it still doesn't have the lock, and go to the back of the queue. It's possible that's only for Wait/Notify, but I have a sneaking suspicion it's for locking as well.

I definitely wouldn't rely on it - if you need things to occur in a sequence, build up a Queue<T> or something similar.

EDIT: I've just found this within Joe Duffy's Concurrent Programming on Windows which basically agrees:

Because monitors use kernel objects internally, they exhibit the same roughly-FIFO behavior that the OS synchronization mechanisms also exhibit (described in the previous chapter). Monitors are unfair, so if another thread tries to acquire the lock before an awakened waiting thread tries to acquire the lock, the sneaky thread is permitted to acquire a lock.

The "roughly-FIFO" bit is what I was thinking of before, and the "sneaky thread" bit is further evidence that you shouldn't make assumptions about FIFO ordering.

Normal CLR locks are not guaranteed to be FIFO.

But, there is a QueuedLock class in this answer which will provide a guaranteed FIFO locking behavior.

The lock statement is documented to use the Monitor class to implement its behavior, and the docs for the Monitor class make no mention (that I can find) of fairness. So you should not rely on requested locks being acquired in the order of request.

In fact, an article by Jeffery Richter indicates in fact lock is not fair:

• Thread Synchronization Fairness in the .NET CLR

Granted - it's an old article so things may have changed, but given that no promises are made in the contract for the Monitor class about fairness, you need to assume the worst.

Slightly tangential to the question, but ThreadPool doesn't even guarantee that it will execute queued work items in the order they are added. If you need sequential execution of asynchronous tasks, one option is using TPL Tasks (also backported to .NET 3.5 via Reactive Extensions). It would look something like this:

public static void Test()
{
    var states = new List<State>();

    _dueTime = DateTime.Now.AddSeconds(5);

    var initialState = new State() { Index = 0 };
    var initialTask = new Task(Go, initialState);
    Task priorTask = initialTask;

    for (int i = 1; i < 10; i++)
    {
        var state = new State { Index = i };
        priorTask = priorTask.ContinueWith(t => Go(state));

        states.Add(state);
        Thread.Sleep(100);
    }
    Task finalTask = priorTask;

    initialTask.Start();
    finalTask.Wait();
}

This has a few advantages:

1. Execution order is guaranteed.

2. You no longer require an explicit lock (the TPL takes care of those details).

3. You no longer need events and no longer need to wait on all events. You can simply say: wait for the last task to complete.

4. If an exception were thrown in any of the tasks, subsequent tasks would be aborted and the exception would be rethrown by the call to Wait. This may or may not match your desired behavior, but is generally the best behavior for sequential, dependent tasks.

5. By using the TPL, you have added flexibility for future expansion, such as cancellation support, waiting on parallel tasks for continuation, etc.