What are the important threading API calls to understand before writing multi-threaded code?

Recently I was blogging about the oft over-used ide开发者_Go百科a of multi-threading in .Net. I put together a staring list for "APIs you should know first":

• Thread
• ThreadPool
• ManualResetEvent
• AutoResetEvent
• EventWaitHandle
• WaitHandle
• Monitor
• Mutex
• Semaphore
• Interlocked
• BackgroundWorker
• AsyncOperation
• lock Statement
• volatile
• ThreadStaticAttribute
• Thread.MemoryBarrier
• Thread.VolatileRead
• Thread.VolatileWrite

Then I started thinking maybe not all of these are important. For instance, Thread.MemoryBarrier could probably be safely removed from the list. Add to that the obvious statement that I don't know everything and I decided to turn here.

So this is a broad and opinionated question, but I'm curious as to the collective's opinion as to a best-practice study list. Essentially I'm looking for a short hit list for new and/or Jr. developers to work from when beginning to write multi-threading code in C#.

So without further commentary, what should be added or removed from the above list?

I think you need to classify the levels of multithreading, not the different API's. Depending on your threading needs, you may or may not need to know certain subsets of the API's you have listed. If I were to organize them, I would do it along these lines:

• Basic Multi-threading:
  • Requirements
    1. Need to run concurrent processes.
    2. Do not need access to shared resources.
    3. Maximizing utilization of available hardware resources.
  • API Knowledge
    1. Thread
    2. ThreadPool
    3. BackgroundWorker
    4. Asynchronous Operations/Delegates
• Shared Resource Multi-threading:
  • Requirements
    1. Basic Multi=-threading requirements
    2. Use of shared resources
  • API Knowledge
    1. Basic Multi-threading API's
    2. lock()/Monitor (they are the same thing)
    3. Interlocked
    4. ReaderWriterLock and variants
    5. volatile
• Multi-thread Synchronization
  • Requirements
    1. Basic Multi=-threading requirements
    2. Shared Resource Multi-threading requirements
    3. Synchronization of behavior across multiple threads
  • API Knowledge
    1. Basic Multi-threading API's
    2. Shared Resource Multi-threading API's
    3. WaitHandle
    4. Manual/AutoResetEvent
    5. Mutex
    6. Semaphore
• Concurrent Shared Resource Multi-threading (hyperthreading)
  • Requirements
    1. Basic Multi=-threading requirements
    2. Shared Resource Multi-threading requirements
    3. Concurrent read/write access to shared collections
  • API Knowledge
    1. Basic Multi-threading API's
    2. Shared Resource Multi-threading API's
    3. Parallel Extensions to .NET/.NET 4.0

The rest of the API's I would simply lump into general threading knowledge, stuff that could be picked up as needed, as they fit into all three levels. Things like MemoryBarrier are pretty fringe, and there are usually better ways to accomplish the same thing it accomplishes, with less ambiguity into their behavior and meaning.

IMHO BackgroundWorker should be on the VERY top of your list.

It's fairly simple to explain. Can be used in most cases and delivers a lot of "bang for the buck". For somebody new to threading this gives him something to actually work with without having to learn hours before he does the first thing right.

how about the ParameterizedThreadStart and ThreadStart delegates ?

.NET 4.0 will be bringing some new tools to this problem; many of these tools will hide the details of the low-level threading APIs. You can start getting ready to leverage this new functionality today by doing things such as using LINQ or learning functional-programming techniques.

I'd recommend looking at the Parallel Extensions coming in .NET 4.0, the ThreadPool, BackgroundWorker (if they're working in WinForms) and the lock keyword. Those provide most of the functionality that you'll need from multi-threading, whilst still being a relatively safe environment in which to experiment. Also, you should add the Dispatcher from WPF to your list; developers are more likely to come across that than VolatileRead.