¿Cuáles son las limitaciones de un hilo STA en comparación con los hilos MTA?

Question

Si hacemos un hilo STA como este: Thread.SetApartmentState(STA); entonces no se 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é librerías .NET usan este atributo.

Mi pregunta es cuáles son las limitaciones de un hilo con estado de apartamento establecido en STA, en comparación con los hilos con estado de apartamento MTA (hilos naturales .NET)?

Answer 1

y luego no se puede ejecutar el código marcado con el atributo [MTAThread].

Así no es como funciona. El tipo de apartamento es propiedad de un hilo, no de un método. Verá que el atributo [STAThread] se aplica 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 subproceso. Más allá de eso, el atributo no tiene ningún significado, el hilo permanece en una STA para su duración. Nunca se ve [MTAThread] porque ese es el valor predeterminado.

Un hilo que es STA tiene algunas limitaciones. Nunca puede bloquear porque eso bloqueará y a menudo interbloqueará cualquier código que intente llamar a un método de un objeto COM con rosca de apartamento. Y debe bombear un bucle de mensaje para que COM pueda ordenar la llamada a método de otro hilo. Las llamadas al método Marshaled solo se pueden ejecutar cuando un hilo está 'inactivo', no está ocupado ejecutando ningún código. Un ciclo 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 admitidos por Automation para que se pueda utilizar el marcador estándar. O proporcionando un par proxy/stub para una clasificación personalizada. La clave de registro determina cómo se realiza la clasificación.

Compartir un objeto de apartamento roscado entre una STA y un subproceso de MTA es explícitamente compatible. El subproceso STA debe crearlo, cualquier llamada en el subproceso MTA (u otros subprocesos STA) se clasifica. Lo que garantiza que el componente solo ve llamadas realizadas en el mismo subproceso, lo que garantiza la seguridad del subproceso. No se requiere bloqueo adicional.

Por último pero no menos importante, si crea un objeto COM de subprocesamiento 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 cálculo de referencias. La única desventaja de hacerlo de esta manera es que cada llamada se calculará. Eso es lento

Answer 2

No creo que marque la diferencia si no utiliza COM. Si lo hace, en algunos casos, los objetos COM solo pueden ser accesibles desde uno u otro tipo de subproceso. Si el objeto COM funciona en ambos apartamentos, intente realizar pruebas de rendimiento. O lea sobre COM apartments en MSDN. Pero no creo que importe para el rendimiento, es más bien una elección de diseño o algo así.