¿Por qué algunos objetos no son accesibles desde diferentes subprocesos?

Question

Me he encontrado con este problema varias veces durante el desarrollo en C#. Voy a ser un feliz a lo largo de codificación, los objetos que pasan de aquí para allá entre los hilos y lo que no, entonces, de repente, me sale este error familiar:

"The calling thread cannot access this object because a different thread owns it."

Pues bien, he tratado con él antes, especialmente con objetos en el hilo de la GUI. Solo tiene que escribir un código adicional para programar alrededor de ese problema específico. Pero de vez en cuando me encuentro con un objeto que, por supuesto, es ordinario, pero que no le gusta ser accedido por diferentes hilos.

EDIT Me equivocaron en mi publicación original sobre el objeto que causaba la excepción de acceso. NO fue IPAddress, en su lugar es System.Printing.PrintQueue. que estaba utilizando para obtener la dirección IP. Este es el objeto que no puede evaluar a partir de más de 1 hilo.

Todas mis clases que he escrito nunca tienen este problema. Ni siquiera sé cómo implementaría esto yo mismo. ¿Tendrías que mantener una variable miembro con la identificación del hilo que te creó, y luego verificar el hilo actual contra eso en cada propiedad y acceso al método? Eso parece una locura. ¿Por qué Microsoft decidiría que ... "OK ... PrintQueue, definitivamente no se puede compartir entre hilos. Pero estas otras clases ... están bien para ir".

¿Por qué se bloquean algunos objetos del acceso a múltiples subprocesos?

Answer 1

Creo que esto puede explicar bastante bien las cosas, creo que esto específicamente tiene que ver con COM.

http://msdn.microsoft.com/en-us/library/ms693344%28v=vs.85%29

específicamente.

In general, the simplest way to view the COM threading architecture is to think of all the COM objects in the process as divided into groups called apartments. A COM object lives in exactly one apartment, in the sense that its methods can legally be directly called only by a thread that belongs to that apartment. Any other thread that wants to call the object must go through a proxy.

There are two types of apartments: single-threaded apartments, and multithreaded apartments.

Single-threaded apartments consist of exactly one thread, so all COM objects that live in a single-threaded apartment can receive method calls only from the one thread that belongs to that apartment. All method calls to a COM object in a single-threaded apartment are synchronized with the windows message queue for the single-threaded apartment's thread. A process with a single thread of execution is simply a special case of this model.

Multithreaded apartments consist of one or more threads, so all COM objects that live in an multithreaded apartment can receive method calls directly from any of the threads that belong to the multithreaded apartment. Threads in a multithreaded apartment use a model called free-threading. Calls to COM objects in a multithreaded apartment are synchronized by the objects themselves.