Управляемые и неуправляемые потоки в Windows Managed and unmanaged threading in Windows

Управление всеми потоками осуществляется посредством класса Thread , включая потоки, созданные средой CLR или созданные за пределами среды выполнения и входящие в управляемую среду для выполнения кода. Management of all threads is done through the Thread class, including threads created by the common language runtime and those created outside the runtime that enter the managed environment to execute code. Среда выполнения отслеживает в своем процессе все потоки, которые когда-либо выполняли код в управляемой среде. The runtime monitors all the threads in its process that have ever executed code within the managed execution environment. Другие потоки она не отслеживает. It does not track any other threads. Потоки могут входить в управляемую среду выполнения посредством COM-взаимодействия (так как среда выполнения предоставляет управляемые объекты неуправляемой среде в качестве COM-объектов), функции COM DllGetClassObject и вызова неуправляемого кода. Threads can enter the managed execution environment through COM interop (because the runtime exposes managed objects as COM objects to the unmanaged world), the COM DllGetClassObject function, and platform invoke.

Когда неуправляемый поток входит в среду выполнения, например, посредством вызываемой оболочки COM, система проверяет локальное хранилище потока данного потока для поиска внутреннего управляемого объекта Thread . When an unmanaged thread enters the runtime through, for example, a COM callable wrapper, the system checks the thread-local store of that thread to look for an internal managed Thread object. Если он найден, среда выполнения уже оповещена об этом потоке. If one is found, the runtime is already aware of this thread. Если найти объект не удается, среда выполнения создает новый объект Thread и устанавливает его в локальном хранилище потока данного потока. If it cannot find one, however, the runtime builds a new Thread object and installs it in the thread-local store of that thread.

При использовании управляемых потоков Thread.GetHashCode является стабильным средством идентификации управляемого потока. In managed threading, Thread.GetHashCode is the stable managed thread identification. В течение времени существования вашего потока он не будет конфликтовать со значением из любого другого потока независимо от того, из какого домена приложения вы получили это значение. For the lifetime of your thread, it will not collide with the value from any other thread, regardless of the application domain from which you obtain this value.

Сопоставление потоков Win32 с управляемыми потоками Mapping from Win32 threading to managed threading

В следующей таблице элементы потоков Win32 сопоставляются со своими ближайшими аналогами из среды выполнения. The following table maps Win32 threading elements to their approximate runtime equivalent. Обратите внимание, что такое сопоставление не означает идентичную функциональность. Note that this mapping does not represent identical functionality. Например, TerminateThread не выполняет предложения finally , не освобождает ресурсы и не может быть запрещен. For example, TerminateThread does not execute finally clauses or free up resources, and cannot be prevented. Однако Thread.Abort выполняет весь ваш код отката, освобождает все ресурсы и может быть отменен с помощью ResetAbort. However, Thread.Abort executes all your rollback code, reclaims all the resources, and can be denied using ResetAbort. Прежде чем делать предположения о функциональности, тщательно изучите документацию. Be sure to read the documentation closely before making assumptions about functionality.

В Win32 In Win32	В среде CLR In the common language runtime
CreateThread CreateThread	Сочетание Thread и ThreadStart Combination of Thread and ThreadStart
TerminateThread TerminateThread	Thread.Abort
SuspendThread SuspendThread	Thread.Suspend
ResumeThread ResumeThread	Thread.Resume
Sleep Sleep	Thread.Sleep
WaitForSingleObject в дескрипторе потока WaitForSingleObject on the thread handle	Thread.Join
ExitThread ExitThread	Эквивалент отсутствует No equivalent
GetCurrentThread GetCurrentThread	Thread.CurrentThread
SetThreadPriority SetThreadPriority	Thread.Priority
Эквивалент отсутствует No equivalent	Thread.Name
Эквивалент отсутствует No equivalent	Thread.IsBackground
Близко к CoInitializeEx (OLE32.DLL) Close to CoInitializeEx (OLE32.DLL)	Thread.ApartmentState

Управляемые потоки и подразделения COM Managed threads and COM apartments

Управляемый поток может быть отмечен для указания того, что в нем будет размещаться однопотоковое или многопотоковое подразделение. A managed thread can be marked to indicate that it will host a single-threaded or multithreaded apartment. (Дополнительные сведения об архитектуре потоков COM см. в статье Processes, Threads, and Apartments (Процессы, потоки и подразделения)). Методы GetApartmentState, SetApartmentState и TrySetApartmentState класса Thread возвращают и назначают состояние подразделения потока. (For more information on the COM threading architecture, see Processes, Threads, and Apartments.) The GetApartmentState, SetApartmentState, and TrySetApartmentState methods of the Thread class return and assign the apartment state of a thread. Если состояние не задано, GetApartmentState возвращает ApartmentState.Unknown. If the state has not been set, GetApartmentState returns ApartmentState.Unknown.

Свойство можно задать, только когда поток находится в состоянии ThreadState.Unstarted ; его можно задать только один раз для потока. The property can be set only when the thread is in the ThreadState.Unstarted state; it can be set only once for a thread.

Если состояние подразделения не задано до запуска потока, этот поток инициализируется в качестве многопотокового подразделения (MTA). If the apartment state is not set before the thread is started, the thread is initialized as a multithreaded apartment (MTA). Поток метода завершения и все потоки, управляемые ThreadPool , являются многопотоковыми подразделениями. The finalizer thread and all threads controlled by ThreadPool are MTA.

Для кода запуска приложения единственный способ управления состоянием подразделения заключается в применении MTAThreadAttribute или STAThreadAttribute к процедуре точки входа. For application startup code, the only way to control apartment state is to apply the MTAThreadAttribute or the STAThreadAttribute to the entry point procedure.

Управляемые объекты, предоставляемые интерфейсу COM, работают так, как если бы они агрегировали упаковщик в режиме свободного потока. Managed objects that are exposed to COM behave as if they had aggregated the free-threaded marshaler. Другими словами, их можно вызвать из любого подразделения COM в режиме свободного потока. In other words, they can be called from any COM apartment in a free-threaded manner. В таком режиме не работают только управляемые объекты, производные от ServicedComponent или StandardOleMarshalObject. The only managed objects that do not exhibit this free-threaded behavior are those objects that derive from ServicedComponent or StandardOleMarshalObject.

В управляемом коде отсутствует поддержка SynchronizationAttribute , если только вы не используете контексты и контекстно-привязанные управляемые экземпляры. In the managed world, there is no support for the SynchronizationAttribute unless you use contexts and context-bound managed instances. Если вы используете корпоративные службы, ваш объект должен быть производным от ServicedComponent (который сам является производным от ContextBoundObject). If you are using Enterprise Services, then your object must derive from ServicedComponent (which is itself derived from ContextBoundObject).

Когда управляемый код вызывает COM-объекты, он всегда следует правилам COM. When managed code calls out to COM objects, it always follows COM rules. Другими словами, он выполняет вызов через прокси-серверы подразделения COM и оболочки контекста COM+ 1.0, как того требует OLE32. In other words, it calls through COM apartment proxies and COM+ 1.0 context wrappers as dictated by OLE32.

Блокирующие проблемы Blocking issues

Если поток выполняет неуправляемый вызов для операционной системы, которая заблокировала этот поток в неуправляемом коде, среда выполнения не берет на себя управление им для Thread.Interrupt или Thread.Abort. If a thread makes an unmanaged call into the operating system that has blocked the thread in unmanaged code, the runtime will not take control of it for Thread.Interrupt or Thread.Abort. В случае с Thread.Abortсреда выполнения помечает поток как Abort и берет управление, когда он повторно входит в управляемый код. In the case of Thread.Abort, the runtime marks the thread for Abort and takes control of it when it re-enters managed code. Вместо неуправляемой блокировки рекомендуется использовать управляемую блокировку. It is preferable for you to use managed blocking rather than unmanaged blocking. WaitHandle.WaitOne,WaitHandle.WaitAny, WaitHandle.WaitAll, Monitor.Enter, Monitor.TryEnter, Thread.Join, GC.WaitForPendingFinalizers и др. реагируют на Thread.Interrupt и Thread.Abort. WaitHandle.WaitOne,WaitHandle.WaitAny, WaitHandle.WaitAll, Monitor.Enter, Monitor.TryEnter, Thread.Join, GC.WaitForPendingFinalizers, and so on are all responsive to Thread.Interrupt and to Thread.Abort. Кроме того, если ваш поток находится в однопотоковом подразделении, все эти операции управляемой блокировки будут корректно выдавать сообщения в ваше подразделение, пока поток находится в заблокированном состоянии. Also, if your thread is in a single-threaded apartment, all these managed blocking operations will correctly pump messages in your apartment while your thread is blocked.

Потоки и волокна Threads and fibers

Потоковая модель .NET не поддерживает волокна. The .NET threading model does not support fibers. Не следует вызывать неуправляемые функции, которые реализуется с использованием волокон. You should not call into any unmanaged function that is implemented by using fibers. Такие вызовы могут привести к сбою среды выполнения .NET. Such calls may result in a crash of the .NET runtime.

Managed and unmanaged threading in Windows

Management of all threads is done through the Thread class, including threads created by the common language runtime and those created outside the runtime that enter the managed environment to execute code. The runtime monitors all the threads in its process that have ever executed code within the managed execution environment. It does not track any other threads. Threads can enter the managed execution environment through COM interop (because the runtime exposes managed objects as COM objects to the unmanaged world), the COM DllGetClassObject function, and platform invoke.

When an unmanaged thread enters the runtime through, for example, a COM callable wrapper, the system checks the thread-local store of that thread to look for an internal managed Thread object. If one is found, the runtime is already aware of this thread. If it cannot find one, however, the runtime builds a new Thread object and installs it in the thread-local store of that thread.

In managed threading, Thread.GetHashCode is the stable managed thread identification. For the lifetime of your thread, it will not collide with the value from any other thread, regardless of the application domain from which you obtain this value.

Mapping from Win32 threading to managed threading

The following table maps Win32 threading elements to their approximate runtime equivalent. Note that this mapping does not represent identical functionality. For example, TerminateThread does not execute finally clauses or free up resources, and cannot be prevented. However, Thread.Abort executes all your rollback code, reclaims all the resources, and can be denied using ResetAbort. Be sure to read the documentation closely before making assumptions about functionality.

In Win32	In the common language runtime
CreateThread	Combination of Thread and ThreadStart
TerminateThread	Thread.Abort
SuspendThread	Thread.Suspend
ResumeThread	Thread.Resume
Sleep	Thread.Sleep
WaitForSingleObject on the thread handle	Thread.Join
ExitThread	No equivalent
GetCurrentThread	Thread.CurrentThread
SetThreadPriority	Thread.Priority
No equivalent	Thread.Name
No equivalent	Thread.IsBackground
Close to CoInitializeEx (OLE32.DLL)	Thread.ApartmentState

Managed threads and COM apartments

A managed thread can be marked to indicate that it will host a single-threaded or multithreaded apartment. (For more information on the COM threading architecture, see Processes, Threads, and Apartments.) The GetApartmentState, SetApartmentState, and TrySetApartmentState methods of the Thread class return and assign the apartment state of a thread. If the state has not been set, GetApartmentState returns ApartmentState.Unknown.

The property can be set only when the thread is in the ThreadState.Unstarted state; it can be set only once for a thread.

If the apartment state is not set before the thread is started, the thread is initialized as a multithreaded apartment (MTA). The finalizer thread and all threads controlled by ThreadPool are MTA.

For application startup code, the only way to control apartment state is to apply the MTAThreadAttribute or the STAThreadAttribute to the entry point procedure.

Managed objects that are exposed to COM behave as if they had aggregated the free-threaded marshaler. In other words, they can be called from any COM apartment in a free-threaded manner. The only managed objects that do not exhibit this free-threaded behavior are those objects that derive from ServicedComponent or StandardOleMarshalObject.

In the managed world, there is no support for the SynchronizationAttribute unless you use contexts and context-bound managed instances. If you are using Enterprise Services, then your object must derive from ServicedComponent (which is itself derived from ContextBoundObject).

When managed code calls out to COM objects, it always follows COM rules. In other words, it calls through COM apartment proxies and COM+ 1.0 context wrappers as dictated by OLE32.

Blocking issues

If a thread makes an unmanaged call into the operating system that has blocked the thread in unmanaged code, the runtime will not take control of it for Thread.Interrupt or Thread.Abort. In the case of Thread.Abort, the runtime marks the thread for Abort and takes control of it when it re-enters managed code. It is preferable for you to use managed blocking rather than unmanaged blocking. WaitHandle.WaitOne,WaitHandle.WaitAny, WaitHandle.WaitAll, Monitor.Enter, Monitor.TryEnter, Thread.Join, GC.WaitForPendingFinalizers, and so on are all responsive to Thread.Interrupt and to Thread.Abort. Also, if your thread is in a single-threaded apartment, all these managed blocking operations will correctly pump messages in your apartment while your thread is blocked.

Threads and fibers

The .NET threading model does not support fibers. You should not call into any unmanaged function that is implemented by using fibers. Such calls may result in a crash of the .NET runtime.