c# - ¿Cuáles son las limitaciones de un hilo STA en comparación con los hilos MTA?
multithreading (2)
Si hacemos un hilo de STA como este: Thread.SetApartmentState(STA); entonces no puede ejecutar el código marcado con el atributo [MTAThread] .
Hemos visto [STAThread] en aplicaciones de Windows y consola, pero nunca he visto código con el atributo [MTAThread] y no sé qué bibliotecas .NET usan este atributo.
Mi pregunta es ¿cuáles son las limitaciones de un subproceso con el estado de apartamento establecido en STA, en comparación con los subprocesos con el estado de apartamento de MTA (subprocesos de .NET naturales)?
entonces no puede ejecutar el código marcado con el atributo [MTAThread].
Así no es cómo funciona. El tipo de apartamento es una propiedad de un hilo, no de un método. Verá el atributo [STAThread] aplicado solo al método Main () de un programa .NET. Determina el tipo de apartamento del primer hilo que se crea para ejecutar el programa. Necesario porque no puede llamar a SetApartmentState () después de que se esté ejecutando el hilo. Más allá de eso, el atributo no tiene significado, el hilo permanece en una STA durante su vida útil. Nunca ves [MTAThread] porque ese es el valor predeterminado.
Un hilo que es STA tiene algunas limitaciones. Nunca se puede bloquear porque eso bloqueará y con frecuencia bloqueará cualquier código que intente llamar a un método de un objeto COM de subproceso de apartamento. Y debe bombear un bucle de mensajes para que COM pueda calcular la llamada al método desde otro hilo. Las llamadas de método enganchadas solo pueden ejecutarse cuando un subproceso está ''inactivo'', no ocupado en ejecutar ningún código. Un bucle de mensajes proporciona ese estado "no ocupado".
También hay requisitos en el componente COM. Debe admitir el cálculo de referencias, ya sea restringiéndose al subconjunto de tipos que son compatibles con la automatización para que se pueda utilizar el contador de referencias estándar. O al proporcionar un par proxy / stub para el cálculo de referencias personalizado. La clave de registro HKCR/Interface/{iid}/ProxyStubClsid32 determina cómo se realiza el HKCR/Interface/{iid}/ProxyStubClsid32 .
El uso compartido de un objeto con hilo de apartamento entre una STA y un subproceso MTA se admite explícitamente. El subproceso STA debe crearlo, cualquier llamada en el subproceso MTA (u otros subprocesos STA) se calcula. Lo que garantiza que el componente solo vea las llamadas realizadas en el mismo hilo, asegurando así la seguridad del hilo. No se requiere bloqueo adicional.
Por último, pero no menos importante, si crea un objeto COM de subproceso de apartamento en un subproceso MTA, COM creará automáticamente un subproceso STA para darle un hogar seguro. El único modo de falla para esto es cuando el componente COM no admite el cálculo de referencias. La única desventaja de hacerlo de esta manera es que cada llamada será calculada. Eso es lento
No creo que haga ninguna diferencia si no usas COM. Si lo hace, entonces en algunos casos, los objetos COM pueden ser accesibles solo desde uno u otro tipo de hilo. Si el objeto COM funciona en ambos apartamentos, intente realizar pruebas de rendimiento. O lea acerca de los apartamentos COM en MSDN. Pero no creo que importe para el rendimiento, es más bien una elección de diseño o algo así.