Тъй като AppDomin.GetCurrentThreadId() е остарял
„AppDomain.GetCurrentThreadId е остарял, защото не предоставя стабилен идентификатор, когато управляваните нишки се изпълняват на влакна (известни още като леки нишки). За да получите стабилен идентификатор за управлявана нишка, използвайте свойството ManagedThreadId на Thread. 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" атомен, или дори е възможно?
