Поскольку AppDomin.GetCurrentThreadId() устарел
«AppDomain.GetCurrentThreadId устарел, поскольку он не предоставляет стабильный идентификатор, когда управляемые потоки выполняются на волокнах (также называемых облегченными потоками). Чтобы получить стабильный идентификатор для управляемого потока, используйте свойство ManagedThreadId в потоке. http://go.microsoft.com/fwlink/?linkid=14202"
Я старался не использовать его. Однако объяснение того, что «Thread.CurrentThread.ManagedThreadId» будет работать, бесполезно, потому что оно не предоставляет идентификатор потока Win32, который мне нужен для вызовов Win32. Поэтому я реализовал это сам следующим образом.
public sealed class AppDomainExtender
{
public static int GetCurrentThreadId_New()
{
return Process.GetCurrentProcess().Threads.OfType<ProcessThread>().SingleOrDefault(x => x.ThreadState == System.Diagnostics.ThreadState.Running).Id;
}
}
Теперь есть две проблемы.
- Если бы это сработало, разве это не было бы точно так же, как AppDomain.GetCurrentThreadId?
- Это не работает по той причине, что работающий поток может измениться при прохождении цикла SingleOrDefault. Это странное поведение, но оно только что привело меня к InvalidOperationException ("Последовательность содержит более одного элемента"). По-видимому, это происходит, например, при использовании нескольких рабочих столов (я предполагаю, что это возможно только путем копирования потока, выполняющего цикл, на другой идентификатор).
Вопросы:
- Является ли AppDomain.GetCurrentThreadId ложно объявленным устаревшим?
- Как можно сделать оператор «Process.GetCurrentProcess().Threads.OfType().SingleOrDefault(x => x.ThreadState == System.Diagnostics.ThreadState.Running).Id» атомарным, или это вообще возможно?
