Multi-core and its exploitation has brought a number of challenges to the programming world. It’s clear that we need to exploit the many cores that are now available to us, but it can be hard work to manage and coordinate the activities that are running on many threads. Fortunately, from the .NET 4 framework onwards, the Task Parallel Library (TPL) has given us excellent abstractions for working in this world.
Tasks abstract the notion of a unit of work, and the library offers ways to coordinate tasks and add dependencies between them, allowing tasks to notify each other of completion and hence get ordering guarantees. The TPL has a great cancellation model based on cooperative cancellation via the CancellationToken type and its methods which allow user code to regularly poll the token and throw an exception if a cancellation is desired. The TPL has a special well known exception that is used to communicate the co-operative cancellation of a task.
With all of this, it was strange to see a post discussing problems with framework classes when Thread.Abort is used. In code you see every day, very few classes would handle Thread.Abort raising an exception at some arbitrary place in the code. You can try to put a finally or catch around the state changing code, but of course, a second Thread.Abort could happen during the running of the fixup code. To harden the code sufficiently to handle this would be both impractical and a real waste of programmer time, and until we get truly transactional objects injecting an exception onto a thread is simply something you should not do. Joe Duffy covers this brilliantly in this post.