Какие важные вызовы API потоков необходимо понять, прежде чем писать многопоточный код?

Недавно я писал в блоге о часто используемой идее многопоточности в .Net. Я собрал начальный список для "API, которые вы должны знать в первую очередь":

  • Нить
  • ThreadPool
  • ManualResetEvent
  • AutoResetEvent
  • EventWaitHandle
  • WaitHandle
  • монитор
  • Mutex
  • семафор
  • Interlocked
  • BackgroundWorker
  • AsyncOperation
  • Заявление о блокировке
  • летучий
  • ThreadStaticAttribute
  • Thread.MemoryBarrier
  • Thread.VolatileRead
  • Thread.VolatileWrite

Тогда я начал думать, может быть, не все из них важны. Например, Thread.MemoryBarrier может быть безопасно удален из списка. Добавьте к этому очевидное утверждение, что я не знаю всего, и я решил обратиться сюда.

Так что это широкий и самоуверенный вопрос, но мне любопытно мнение коллектива относительно списка лучших практик. По сути, я ищу короткий список совпадений для новых и / или младших разработчиков, с которых нужно начинать писать многопоточный код на C #.

Итак, без дальнейших комментариев, что следует добавить или удалить из приведенного выше списка?

12.10.2009 23:42:37
5 ОТВЕТОВ
РЕШЕНИЕ

Я думаю, вам нужно классифицировать уровни многопоточности, а не разные API. В зависимости от ваших потребностей в потоках, вам может понадобиться или не потребоваться знать определенные подмножества API, которые вы перечислили. Если бы я организовал их, я сделал бы это следующим образом:

  • Базовая многопоточность:
    • Требования
      1. Необходимо запустить параллельные процессы.
      2. Не нужен доступ к общим ресурсам.
      3. Максимальное использование доступных аппаратных ресурсов.
    • Знание API
      1. Нить
      2. ThreadPool
      3. BackgroundWorker
      4. Асинхронные операции / Делегаты
  • Многопоточность общего ресурса:
    • Требования
      1. Основные требования Multi-Threading
      2. Использование общих ресурсов
    • Знание API
      1. Основные многопоточные API
      2. блокировка () / монитор (это одно и то же)
      3. Interlocked
      4. ReaderWriterLock и варианты
      5. летучий
  • Многопоточная синхронизация
    • Требования
      1. Основные требования Multi-Threading
      2. Требования к многопоточности общего ресурса
      3. Синхронизация поведения в нескольких потоках
    • Знание API
      1. Основные многопоточные API
      2. Многопоточные API общего ресурса
      3. WaitHandle
      4. Руководство / AutoResetEvent
      5. Mutex
      6. семафор
  • Многопоточность параллельных общих ресурсов (гиперпоточность)
    • Требования
      1. Основные требования Multi-Threading
      2. Требования к многопоточности общего ресурса
      3. Параллельный доступ на чтение / запись к общим коллекциям
    • Знание API
      1. Основные многопоточные API
      2. Многопоточные API общего ресурса
      3. Параллельные расширения до .NET / .NET 4.0

Остальные API я бы просто погрузил в общие знания о потоках, вещи, которые можно было бы подобрать по мере необходимости, так как они вписываются во все три уровня. Такие вещи, как MemoryBarrier, довольно незначительны, и, как правило, существуют лучшие способы достичь того же, что и он, с меньшей неопределенностью в их поведении и значении.

6
12.10.2009 23:57:33
+1 Согласен, определенно многое можно сделать, чтобы организовать и расставить приоритеты в информации. Основной хит-лист казался подходящим первым шагом.
csharptest.net 13.10.2009 00:06:57

как насчет делегатов ParameterizedThreadStart и ThreadStart?

1
12.10.2009 23:52:04

Я бы порекомендовал взглянуть на Parallel Extensions, входящие в .NET 4.0 , ThreadPool, BackgroundWorker (если они работают в WinForms) и ключевое слово lock. Они предоставляют большую часть функциональности, которая вам понадобится в многопоточности, и в то же время являются относительно безопасной средой для экспериментов. Также вы должны добавить Dispatcher из WPF в свой список; разработчики чаще сталкиваются с этим, чем VolatileRead.

0
12.10.2009 23:52:13

ИМХО BackgroundWorker должен быть в ОЧЕНЬ верхней части вашего списка.

Это довольно просто объяснить. Может использоваться в большинстве случаев и обеспечивает большую отдачу. Для кого-то новичка в потоке это дает ему возможность по-настоящему работать без необходимости учиться часами, прежде чем он сделает все правильно.

4
13.10.2009 00:01:25
Я не уверен, что согласился бы. BackgroundWorker хорош своей простотой, но погружение и использование его без какого-либо предварительного знания предостережений о многопоточном кодировании может легко и, скорее всего, приведет к таким проблемам, как неправильный вызов методов / свойств управления пользовательским интерфейсом, использование общих ресурсов, и т.д. Я даже не могу сосчитать, сколько раз какой-то младший разработчик начал использовать BackgroundWorker, а затем потратил часы или дни, пытаясь решить проблему вызова пользовательского интерфейса (да, это очевидно, когда вы узнаете об этом, но до этого момента это поскольку неясно , как неясными получает нуб).
jrista 13.10.2009 00:10:52

В .NET 4.0 появятся новые инструменты для решения этой проблемы; Многие из этих инструментов будут скрывать детали низкоуровневых API потоков. Вы можете начать готовиться к использованию этой новой функциональности сегодня, выполняя такие вещи, как использование LINQ или изучение методов функционального программирования.

1
13.10.2009 01:49:54