The Moth

In a quiz I posted recently, I had some replies in the comments (which are incorrect btw) and more replies over emails that were correct (with a caveat). I am referring to question A (and I touched on the motivation for question B here).

In short, the correct answer to (trick) question A is that the only thing guaranteed is breakpoint #5 will be hit last and BP #1 happens before #2 and #3. There is a race between BP #4 and #1 and then a similar race between BP #2 and #3, which means that we cannot tell the overall order.

Now, I mentioned above that there was a caveat: In majority of replies they stressed that even though we cannot tell for sure, it is likely/probable that BP #4 would be hit before #1 due to overhead of setting up the child Task. Indeed if you run that exact code on your dual core machine, you’ll likely/probably find that that is the case. However, this is certainly not guaranteed or expected.

Take the original code: what 2 statements can we insert at the start of Main (before creating Task t1) that will result in BP #1 being hit before BP #4? Here is one answer:

Thread.CurrentThread.Priority = ThreadPriority.Lowest;
TaskManager tm = new TaskManager(new TaskManagerPolicy(1, 1));

...and of course passing tm as the last argument to the Create methods. Try it!

If you think that changing the thread priority was too artificial/contrived, consider that if it is a kernel event that wakes up the scheduler thread it could result in a priority boost, which has a similar risk of causing pre-emption.

If there is one guarantee about what threads run when, it is that there is no guarantee - and any internal engine (CLR, Windows) has the right to change their implementation details anyway so don't rely on empirical findings.