Параллельные операции в .NET

Асинхронный ввод-вывод

Для реализации асинхронного ввода-вывода в .NET предназначен абстрактный класс System.IO.Stream. В этом классе определены абстрактные синхронные методы чтения Read и записи Write, а также реализация асинхронных методов BeginRead, EndRead, BeginWrite и EndWrite. Асинхронные методы реализованы с помощью обращения к синхронным операциям фоновыми потоками пула.

На основе абстрактного класса Stream в .NET Framework реализуются потомки, осуществляющие взаимодействие с разного рода потоками данных. Так, например, System.IO.FileStream реализует операции с файлами, System.IO.MemoryStream предоставляет возможность использования байтового массива в качестве источника или получателя данных, System.IO.BufferedStream является "надстройкой" над другими объектами, производными от System.IO.Stream, и обеспечивает буферизацию запросов чтения и записи. Некоторые классы вне пространства имен Sytem.IO также являются потомками Stream. Так, например, класс System.NET.Sockets.NetworkStream обеспечивает сетевое взаимодействие.

using System;
using System.IO;
namespace TestNamespace {
  class TestApp {
    private const int 	  m_size = 100000000;
    private static byte[]   m_data = new byte [m_size];

    public TestApp()
    {
      int  i;
      for ( i = 0; i < m_size; i++ ) m_data[i] = (byte)i;
    }

    public static void DoneWritting( IAsyncResult state ) {
    }
    static void Main(string[] args) {
      TestApp    	 ta = new TestApp();
      IAsyncResult	 state;
      Stream 		 st = new FileStream(
        "test.dat", FileMode.OpenOrCreate,
        FileAccess.ReadWrite, FileShare.Read, 1, true
      );
      state = st.BeginWrite(
        m_data, 0, m_size,
        new AsyncCallback(DoneWritting), null
      );
      // код в этом месте будет выполняться
      // одновременно с выводом данных
      st.EndWrite( state );
      st.Close();
    }
  }
}

Данный пример демонстрирует использование FileStream для выполнения асинхронной операции записи большого объема данных.

При реализации собственных потомков класса Stream, возможно, будет иметь смысл переопределить не только абстрактные методы Read и Write, но также некоторые базовые (например, BeginRead, ReadByte и др.), универсальная реализация которых может быть неэффективной в конкретном случае.

Асинхронные процедуры

Для реализации вызова асинхронных процедур в .NET используются фоновые потоки пула, так же как для обработки асинхронных операций ввода-вывода. Класс ThreadPool предлагает два способа для вызова асинхронных процедур: явное размещение вызовов в очереди ( QueueUserWorkItem ) и связывание вызовов с переводом некоторых объектов в свободное состояние ( RegisterWaitForSingleObject ). Кроме того, .NET позволяет осуществлять асинхронные вызовы любых процедур с помощью метода BeginInvoke делегатов.

Статический метод ThreadPool.QueueUserWorkItem ставит вызов указанной процедуры в очередь для обработки. Если пул содержит простаивающие потоки, то обработка этой функции начнется немедленно:

using System;
using System.Threading;
namespace TestNamespace {
  class GreetingData {
    private string   m_greeting;
    public GreetingData( string text ) { m_greeting = text; }
    public void Invoke() { Console.WriteLine( m_greeting ); }
  }

  class TestApp {
    static void AsyncProc( Object arg )
    {
      GreetingData  gd = (GreetingData)arg;
      gd.Invoke();
    }

    public static void Main()
    {
      GreetingData gd = new GreetingData("Hello, world!");
      ThreadPool.QueueUserWorkItem(new WaitCallback(AsyncProc), gd);
      Thread.Sleep( 1000 );
    }
  }
}

При постановке в очередь асинхронного вызова можно указать объект, который является аргументом асинхронной процедуры (при создании собственных потоков передача аргументов процедуре потока затруднительна).

Второй способ вызова асинхронных процедур связан с использованием объектов, производных от класса System.Threading.WaitHandle (это события и мьютексы). При этом вызов асинхронной процедуры связывается с переводом объекта в свободное состояние. Данный метод может быть использован также для организации повторяющегося через определенные интервалы вызова асинхронных процедур - при регистрации делегата указывается максимальный интервал ожидания, и если он исчерпывается, то вызов размещается в очереди пула, даже если объект остался занятым. Если объект по-прежнему остается занятым, то вызов процедуры будет периодически размещаться в очереди после исчерпания каждого интервала ожидания.

using System;
using System.Threading;

namespace TestNamespace {
  class GreetingData {
    private string                m_greeting;
    private RegisteredWaitHandle   m_waithandle;
    public GreetingData( string text ) { m_greeting = text; }
    public void Invoke() { Console.WriteLine( m_greeting ); }
    public RegisteredWaitHandle WaitHandle {
      set {
        if (value==null) m_waithandle.Unregister( null );
        m_waithandle = value;
      }
    }
  }
  class TestApp {
    static void AsyncProc( Object arg, bool isTimeout ) {
      GreetingData  gd = (GreetingData)arg;
      if ( !isTimeout ) gd.WaitHandle = null;
      gd.Invoke();
    }
    public static void Main() {
      GreetingData     gd = new GreetingData("Hello");
      AutoResetEvent   ev = new AutoResetEvent(false);
      gd.WaitHandle=ThreadPool.RegisterWaitForSingleObject(
        ev,  new WaitOrTimerCallback(AsyncProc),
        gd,  1000,  false
      );
      Thread.Sleep( 2500 );
      ev.Set();
      Console.ReadLine();
    }
  }
}

Приведенный пример демонстрирует использование периодического вызова асинхронной процедуры - при регистрации делегата ( RegisterWaitForSingleObject ) указывается максимальное время ожидания 1 секунда (1000 миллисекунд), после чего основной поток переводится в состояние "спячки" на 2.5 секунды. За это время в очередь пула поступает два вызова асинхронных процедур (с признаком вызова по тайм-ауту). Через 2.5 секунды основной поток пробуждается, переводит событие в свободное состояние, и в очередь пула поступает третий вызов. При обработке этого вызова регистрация делегата отменяется.

Последний способ связан с использованием методов BeginInvoke и EndInvoke делегатов. Когда определяется какой-либо делегат функции, для него будут определены методы: BeginInvoke (содержащий все аргументы делегата плюс два дополнительных - AsyncCallback, который может быть вызван по завершении обработки асинхронного вызова, и AsyncState, с помощью которого можно определить состояние асинхронной процедуры) и EndInvoke, содержащий все выходные параметры (т.е. описанные как inout или out ), плюс IAsyncResult, позволяющий узнать результат выполнения процедуры.

Таким образом, использование BeginInvoke позволяет не только поставить в очередь вызов асинхронной процедуры, но также связать с завершением ее обработки еще один асинхронный вызов. Метод EndInvoke служит для ожидания завершения обработки асинхронной процедуры:

using System;
using System.Threading;

namespace TestNamespace {
  public class GreetingData {
    private string   m_greeting;
    public GreetingData( string text ) { m_greeting = text; }
    public static void Invoke( GreetingData arg ) {
      Console.WriteLine( arg.m_greeting );
    }
  }
  public delegate void AsyncProcCallback ( GreetingData gd );
  class TestApp {
    public static void Main() {
      GreetingData gd = new GreetingData( "Hello!!!" );
      AsyncProcCallback apd = new AsyncProcCallback(
        GreetingData.Invoke );
      IAsyncResult ar = apd.BeginInvoke( gd, null, null );
      ar.AsyncWaitHandle.WaitOne();
    }
  }
}

Данный пример иллюстрирует вызов асинхронной процедуры с использованием метода BeginInvoke и альтернативный механизм ожидания завершения - с использованием внутреннего объекта AsyncWaitHandle (класса WaitHandle ), благодаря которому, собственно говоря, становится возможен вызов асинхронной процедуры, обслуживающей завершение обработки данной процедуры.

В этом смысле асинхронный вызов процедур с помощью BeginInvoke очень близок к обработке асинхронных операций ввода-вывода.

Синхронизация и изоляция потоков

Проблемы, встающие перед разработчиками многопоточных приложений .NET, очень похожи на проблемы разработчиков приложений Win32 API. Соответственно, .NET предоставляет в значительной мере близкий набор средств взаимодействия потоков и их взаимной синхронизации.

К этим средствам относятся атомарные операции, локальная для потока память, синхронизирующие примитивы и таймеры. Их применение в основе своей похоже на применение аналогичных средств API.

Атомарные операции

Платформа .NET предоставляет, аналогично базовой операционной системе Windows, набор некоторых основных операций над целыми числами ( int и long ), которые могут выполняться атомарно. Для этого предусмотрены четыре статических метода класса System.Threading.Interlocked, а именно Increment, Decrement, Exchange и CompareExchange. Применение этих методов аналогично соответствующим Interlocked... процедурам Win32 API.

Возвращаясь к примеру использования потоков для умножения матриц, можно выделить один момент, требующий исправления: самое начало процедуры потока, там, где определяется номер полосы:

public static void ThreadProc()
{
  int    i,j,k, from, to;
  from = ( m_stripused++ ) * m_stripsize;
  to = from + m_stripsize;
  ...

Здесь потенциально возможна ситуация, когда несколько потоков одновременно начнут выполнять этот код и получат идентичные номера полос. В этом месте самым эффективным было бы использование атомарных операций для увеличения значения поля m_stripused. Для этого фрагмент надо переписать:

public static void ThreadProc()
{
 int    i,j,k, from, to;
 from = (Interlocked.Increment(ref m_stripused) - 1 ) * m_stripsize;
 to = from + m_stripsize;
  ...

Синхронизация потоков

Основные средства взаимной синхронизации потоков в .NET обладают заметным сходством со средствами операционной системы. Среди них можно выделить:

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

Мониторы

Мониторы в .NET являются аналогами критических секций в Win32 API. Использование мониторов достаточно эффективно (это один из самых эффективных механизмов) и удобно настолько, что в .NET был предусмотрен механизм, который позволяет использовать практически любой объект, хранящийся в управляемой куче, для синхронизации доступа. Для этого с каждым объектом ссылочного типа сопоставляется запись SyncBlock, являющаяся, по сути, аналогом структуры CRITICAL_SECTION в Win32 API. Добавление такой записи к каждому объекту в управляемой куче чересчур накладно, особенно если учесть, что используются они относительно редко. Поэтому все записи SyncBlock выносятся в отдельный кэш, а в информацию об объекте включается ссылка на запись кэша (см. рис. 7.2). Такой прием позволяет, с одной стороны, содержать кэш синхронизирующих записей минимального размера, а с другой - любому объекту при необходимости можно сопоставить запись.

Обычно объекты не имеют сопоставленной с ними SyncBlock записи, однако она автоматически выделяется при первом использовании монитора.

Класс Monitor, определенный в пространстве имен System.Threading, предлагает несколько статических методов для работы с записями синхронизации. Методы Enter и Exit являются наиболее применяемыми и соответствуют функциям EnterCriticalSection и LeaveCriticalSection операционной системы. Аналогично критическим секциям Win32 API, мониторы могут использоваться одним потоком рекурсивно. Еще несколько методов класса Monitor - Wait, Pulse и PulseAll - позволяют при необходимости временно разрешить доступ к объекту другому потоку, ожидающему его освобождения, не покидая критической секции.

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

public static void ThreadProc()
{
  int    i,j,k, from, to;
  from = (Interlocked.Increment(ref m_stripused)-1)
    * m_stripsize;
  to = from + m_stripsize;
  if ( to > m_size ) to = m_size;
  for ( i = 0; i < m_size; i++ ) {
    for ( j = 0; j < m_size; j++ ) {
      for ( k = from; k < to; k++ )
        m_C[i,j] += m_A[i,k] * m_B[k,j];
    }
  }
}

Так как эта операция выполняется не атомарно, то вполне может быть так, что один поток считывает значение m_C[i,j], прибавляет к нему величину m_A[i,k] * m_B[k,j] и, прежде чем успевает записать в m_C[i,j] результат сложения, прерывается другим потоком. Второй поток успевает изменить величину m_C[i,j], потом первый снова пробуждается и записывает значение, вычисленное для предыдущего состояния элемента m_C[i,j], - то есть некорректную величину. Собственно говоря, именно эта ситуация и приводит к ошибкам, которые можно наблюдать в исходном примере.

Ситуацию можно исправить, используя синхронизацию при доступе к элементу m_C[i,j] с помощью мониторов:

...
    for ( j = 0; j < m_size; j++ ) {
      for ( k = from; k < to; k++ ) {
        Monitor.Enter( m_C );
        try {
          m_C[i,j] += m_A[i,k] * m_B[k,j];
        } finally {
          Monitor.Exit( m_C );
        }
      }
    }
  ...

В этом фрагменте надо выделить два существенных момента: во-первых, использование метода Exit в блоке finally, а во-вторых - использование всего массива m_C, а не отдельного элемента m_C[i,j].

Первое надо взять за правило, так как в случае возникновения исключения в критической секции блокировка может остаться занятой (т.е. в случае покидания секции без вызова метода Exit ).

Второе связано с тем, что элементы m_C[i,j] являются значениями, а не ссылочными типами. Для типов-значений соответствующее представление в управляемой куче не создается, и у них нет и не может быть ссылок на синхронизирующие записи SyncBlock.

Самое плохое в этой ситуации то, что попытка собрать приложение, использующее типы-значения в качестве аргументов методов Enter и Exit (как в примере ниже), пройдет успешно:

...
    for ( j = 0; j < m_size; j++ ) {
      for ( k = from; k < to; k++ ) {
        Monitor.Enter( m_C[i,j] );
        try {
          m_C[i,j] += m_A[i,k] * m_B[k,j];
        } finally {
          Monitor.Exit( m_C[i,j] );
        }
      }
    }
  ...

В прототипах методов Enter и Exit указано, что они должны получать ссылочный тип object ; соответственно тип-значение будет упакован, и методу Enter будет передан свой экземпляр упакованного типа-значения, на который будет поставлена блокировка, а методу Exit - свой экземпляр, на котором блокировки никогда не было. Понятно, что все остальные потоки будут создавать и множить свои собственные упакованные представления типов-значений, и никакой синхронизации не произойдет. Поэтому при использовании мониторов важно проследить, чтобы вызовы разных методов в разных потоках использовали один общий объект ссылочного типа.

Можно выделить интересный момент - типы объектов сами являются экземплярами класса Type, и для них выделяется место в управляемой куче. Это позволяет использовать тип объекта в качестве владельца записи SyncBlock:

...
    for ( j = 0; j < m_size; j++ ) {
      for ( k = from; k < to; k++ ) {
        Monitor.Enter( typeof(double) );
        try {
          m_C[i,j] += m_A[i,k] * m_B[k,j];
        } finally {
          Monitor.Exit( typeof(double) );
        }
      }
    }
  ...

Возможно неявное использование мониторов в C# с помощью ключевого слова lock:

lock ( obj ) { ... }

эквивалентна

Monitor.Enter( obj ); try { ... }  
finally { Mointor.Exit( obj ); }

Использование ключевого слова lock предпочтительно, так как при этом выполняется дополнительная синтаксическая проверка - попытка использовать для блокировки тип-значение приведет к диагностируемой компилятором ошибке, вместо трудно отлавливаемой ошибки во время исполнения:

public static void ThreadProc()
{
  int  	i,j,k, from, to;
  double  R;
  from = (Interlocked.Increment(ref m_stripused) - 1) * m_stripsize;
  to = from + m_stripsize;
  if ( to > m_size ) to = m_size;
  for ( i = 0; i < m_size; i++ ) {
    for ( j = 0; j < m_size; j++ ) {
      R = 0;
      for ( k = from; k < to; k++ ) R += m_A[i,k]*m_B[k,j];
      lock ( m_C ) { m_C[i,j] += R; }
    }
  }
}

Данный пример показывает процедуру потока, осуществляющего пополосное умножение матриц с необходимой синхронизацией. Следует заметить, что синхронизация доступа требует дополнительных ресурсов процессора (в данном случае, качественно превышающих затраты на умножение и сложение двух чисел с плавающей запятой), поэтому целесообразно как можно сильнее сократить число блокировок и время их наложения. В примере для этого использована промежуточная переменная R, накапливающая частичный результат.

Следует особо подчеркнуть, что мониторы и блокировки доступа только лишь позволяют разработчику реализовать соответствующую синхронизацию, но ни в коем случае не осуществляют принудительное ограничение конкурентного обращения к полям и методам объектов. Любой параллельно выполняющийся фрагмент кода сохраняет полную возможность обращаться со всеми объектами, независимо от того, связаны они с какими-либо блокировками или нет. Для синхронизации и блокирования доступа необходимо, чтобы все участники синхронизации явным образом использовали критические секции.

Ожидающие объекты

.NET предоставляет базовый класс WaitHandle, служащий для описания объекта, который находится в одном из двух состояний: занятом или свободном. На основе этого класса строятся другие классы синхронизирующих объектов .NET, такие как события ( ManualResetEvent и AutoResetEvent ) и мьютексы ( Mutex ).

Класс WaitHandle является, по сути, оберткой объектов ядра операционной системы, поддерживающих интерфейс синхронизации. Свойство Handle объекта WaitHandle позволяет установить (или узнать) соответствие этого объекта .NET с объектом ядра операционной системы.

Существует три метода класса WaitHandle для ожидания освобождения объекта: метод WaitOne, являющийся методом объекта, и статические методы WaitAny и WaitAll. Метод WaitOne является оберткой вызова WaitForSingleObject Win32 API, а методы WaitAny и WaitAll - вызова WaitForMultipleObjects. Соответственно семантике конкретных объектов ядра, представленных объектом WaitHandle, методы Wait... могут изменять или не изменять состояние ожидаемого объекта. Так, например, для событий с ручным сбросом ( ManualResetEvent ) состояние не меняется, а события с автоматическим сбросом и мьютексы ( AutoResetEvent, Mutex ) переводятся в занятое состояние.

Объекты класса WaitHandle и производных от него, представляя объекты ядра операционной системы, могут быть использованы для межпроцессного взаимодействия. Конструкторы производных объектов (событий и мьютексов) позволяют задать имя объекта ядра, предназначенное для организации общего доступа к объектам процессами:

using System;
using System.Threading;

namespace TestNamespace {
  public class SomeData {
    public const int         m_queries = 10;
    private static int       m_counter = 0;
    private static Mutex      m_mutex = new Mutex(); 
    private static ManualResetEvent m_event = 
                new ManualResetEvent( false );
    public static void Invoke( int no ) {
      m_mutex.WaitOne();
      m_counter++;
      if ( m_counter >= m_queries ) m_event.Set();
      m_mutex.ReleaseMutex();
      m_event.WaitOne();
    }
  }
  public delegate void AsyncProcCallback( int no );
  class TestApp {
    public static void Main() {
      int        		i;
      WaitHandle[]    	wh;
      AsyncProcCallback	apd;
      wh = new WaitHandle[ SomeData.m_queries ];
      apd = new AsyncProcCallback( SomeData.Invoke );
      for ( i = 0; i < SomeData.m_queries; i++ ) wh[i] =
			  apd.BeginInvoke(i,null,null).AsyncWaitHandle;
      WaitHandle.WaitAll( wh );
    }
  }
}

Приведенный пример показывает синхронизацию с использованием мьютекса, события с ручным сбросом и объекта WaitHandle, представляющего состояние асинхронного вызова. В примере делается 10 асинхронных вызовов, после чего приложение ожидает завершения всех вызовов с помощью метода WaitAll. Каждый асинхронный метод в секции кода, защищаемой мьютексом (здесь было бы эффективнее использовать монитор или блокировку), подсчитывает число сделанных вызовов и переходит к ожиданию занятого события. Самый последний асинхронный вызов установит событие в свободное состояние, после чего все вызовы должны завершиться.

Помимо использования разных синхронизирующих объектов, в этом примере интересно поведение CLR: асинхронные вызовы должны обрабатываться в пуле потоков, однако число вызовов превышает число потоков в пуле. CLR по мере необходимости добавляет в пул потоки для обработки поступающих запросов.

Потоки не являются наследниками класса WaitHandle в силу того, что для разных базовых платформ потоки могут быть реализованы в качестве потоков операционной системы или легковесных потоков, управляемых CLR. В последнем случае потоки .NET не будут иметь никаких аналогов среди объектов ядра операционной системы. Для синхронизации с потоками надо использовать метод Join класса Thread.

Один "писатель", много "читателей"

Одной из типичных задач синхронизации потоков является задача, в которой допускается одновременный конкурентный доступ многих объектов для чтения данных ("читатели") и исключительный доступ единственного потока, вносящего в объект изменения ("писатель"). В Win32 API стандартного объекта, реализующего подобную логику, не существует, поэтому каждый раз его надо проектировать и создавать заново.

.NET предоставляет весьма эффективное стандартное решение: класс ReaderWriterLock. В приводимом ниже примере демонстрируется применение методов Acquire... и Release... для корректного использования блокировки доступа при чтении и записи. Тестовый класс содержит две целочисленные переменные, которые считываются и увеличиваются на 1 с небольшими задержками по отношению друг к другу. Пока операции синхронизируются, попытка чтения или изменения всегда будет возвращать четный результат, а вот если бы синхронизация не выполнялась, то в некоторых случаях получались бы нечетные числа:

using System;
using System.Threading;
namespace TestNamespace {
  public class SomeData {
    public const int         m_queries = 10;
    private ReaderWriterLock  m_rwlock = new ReaderWriterLock();
    private int        m_a = 0, m_b = 0;
    public int summ() {
      int  r;
      m_rwlock.AcquireReaderLock( -1 );
      try {
        r = m_a; Thread.Sleep( 1000 ); return r + m_b;
      } finally {
        m_rwlock.ReleaseReaderLock();
      }
    }
    public int inc() {
      m_rwlock.AcquireWriterLock( -1 );
      try {
        m_a++; Thread.Sleep( 500 ); m_b++;
        return m_a + m_b;
      } finally {
        m_rwlock.ReleaseWriterLock();
      }
    }
    public static void Invoke( SomeData sd, int no ) {
      if ( no % 2 == 0 ) {
        Console.WriteLine( sd.inc() );
      } else {
        Console.WriteLine( sd.summ() );
      }
    }
  }
  public delegate void AsyncProcCallback(SomeData sd, int no);
  class TestApp {
    public static void Main() {
      int        		i;
      SomeData      	sd = new SomeData();
      WaitHandle[]  	wh;
      AsyncProcCallback  apd;
      wh = new WaitHandle[ SomeData.m_queries ];
      apd = new AsyncProcCallback( SomeData.Invoke );
      for ( i = 0; i < SomeData.m_queries; i++ ) wh[i] =
		     		apd.BeginInvoke(sd,i,null,null).AsyncWaitHandle;
      WaitHandle.WaitAll( wh );
    }
  }
}

Конечно, аналогичного эффекта можно было бы добиться, просто используя блокировку ( lock или методы класса Monitor ) при доступе к объекту. Однако, такой подход потребует наложить блокировку исключительного доступа при чтении данных, что не эффективно. В обычных условиях вполне допустимо чтение данных несколькими одновременно выполняющимися потоками, что может дать заметное ускорение.

Локальная для потока память

Применение локальной для потока памяти в .NET опирается на TLS память, поддерживаемую операционной системой. Аналогично Win32 API, возможны декларативный и императивный подходы для работы с локальной для потока памятью.

Декларативный подход сводится к использованию атрибута ThreadStaticAttribute перед описанием любого статического поля. Например, в следующем фрагменте:

class SomeData {
  [ThreadStatic]
  public static double  xxx;
  ...

Поле класса SomeData.xxx будет размещено в локальной для каждого потока памяти.

Императивный подход связан с применением методов AllocateDataSlot, AllocateNamedDataSlot, GetNamedDataSlot, FreeNamedDataSlot, GetData и SetData класса Thread. Использование этих методов очень похоже на использование Tls... функций Win32 API, с той разницей, что вместо целочисленного индекса в TLS массиве потока (как это было в Win32 API) используется объект типа LocalDataStoreSlot, который выполняет функции прежнего индекса:

class SomeData {
  private static LocalDataStoreSlot m_tls = Thread.AllocateDataSlot();
  public static void ThreadProc() {
    Thread.SetData( m_tls, ... );
    ...
  }
  public void Main() {
    SomeData  sd = new SomeData();
    ...
    // создание и запуск потоков
  }
}

Методы Allocate... и GetNamedDataSlot позволяют выделить новую ячейку в TLS памяти (или получить существующую именованную), методы GetData и SetData позволяют получить или сохранить ссылку на объект в TLS памяти. Использование TLS памяти в .NET менее удобно и эффективно, чем в Win32 API, но это связано не с реализацией TLS, а с реализацией потоков:

Таймеры

.NET предлагает два вида таймеров: один описан в пространстве имен System.Timers, а другой - в пространстве имен System.Threading.

Таймер пространства имен System.Threading является опечатанным и предназначен для вызова указанной асинхронной процедуры с заданным интервалом времени.

Таймер пространства имен System.Timers может быть использован для создания собственных классов-потомков - в нем вместо процедуры асинхронного вызова применяется обработка события, с которым может быть сопоставлено несколько обработчиков. Кроме того, этот таймер может вызывать обработку события конкретным потоком, а не произвольным потоком пула:

using System;
using System.Timers;

namespace TestNamespace {
  class TestTimer : Timer {
    private int m_minimal, m_maximal, m_counter;
    public int count { get{ return m_counter - m_minimal; }}
    public TestTimer( int mn, int mx ) {
      Elapsed += new ElapsedEventHandler(OnElapsed);
      m_minimal = m_counter = mn;
      m_maximal = mx;
      AutoReset = true;
      Interval = 400;
    }
    static void OnElapsed( object src, ElapsedEventArgs e ) {
      TestTimer  tt = (TestTimer)src;
      if ( tt.m_counter < tt.m_maximal ) tt.m_counter++;
      if ( tt.m_counter >= tt.m_maximal ) tt.Stop();
    }
    static void Main(string[] args) {
      TestTimer  tm = new TestTimer( 0, 10 );
      tm.Start();
      Thread.Sleep( 5000 );
      tm.Stop();
    }
  }
}

Приведенный выше пример иллюстрирует использование таймера пространства имен System.Timers.