views:

147

answers:

5

Recently I was blogging about the oft over-used idea 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?

+1  A: 

how about the ParameterizedThreadStart and ThreadStart delegates ?

Andrew Keith
I figured they would get there from the use of Thread.
csharptest.net
A: 

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.

FacticiusVir
+4  A: 

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.

jrista
+1, Agreed, definatly a lot could be done to organize and prioritize the information. A basic hit list seemed the appropriate first step.
csharptest.net
+3  A: 

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.

Foxfire
I am not so sure I would agree. BackgroundWorker is nice for its simplicity, but diving in and using it without any prior knowledge of the caveats of multi-threaded coding can easily, and will most likely, lead to problems like improper invocation of UI control methods/properties, shared resource usage, etc. I can't even count how many times some junior dev has started using BackgroundWorker, and then spent hours or days trying to solve the UI invocation problem (yes, its obvious once you learn about it, but until that moment, it is as obscure as obscure gets to a noob.)
jrista
+1  A: 

.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.

Dan