Potresti spiegare STA e MTA?

Puoi spiegare STA e MTA con parole tue?

Inoltre, quali sono i thread degli appartamenti e riguardano solo COM? Se è così, perché?

Il modello di thread COM viene chiamato un modello “apartment”, in cui il contesto di esecuzione degli oggetti COM inizializzati è associato a un singolo thread (Single Thread Apartment) oa molti thread (Multi Thread Apartment). In questo modello, un object COM, una volta inizializzato in un appartamento, fa parte di quell’appartamento per la durata del suo runtime.

Il modello STA viene utilizzato per gli oggetti COM che non sono thread-safe. Ciò significa che non gestiscono la propria sincronizzazione. Un uso comune di questo è un componente dell’interfaccia utente. Quindi, se un altro thread deve interagire con l’object (come premere un pulsante in un modulo), il messaggio viene marshallato sul thread STA. Il sistema di pompaggio dei messaggi di Windows è un esempio di questo.

Se l’object COM può gestire la propria sincronizzazione, è ansible utilizzare il modello MTA in cui è consentito a più thread di interagire con l’object senza chiamate marshalled.

Tutto dipende da come vengono gestite le chiamate agli oggetti e dalla quantità di protezione di cui hanno bisogno. Gli oggetti COM possono chiedere al runtime di proteggerli dall’essere chiamati da più thread contemporaneamente; quelli che non possono potenzialmente essere chiamati contemporaneamente da diversi thread, quindi devono proteggere i propri dati.

Inoltre, è anche necessario che il runtime impedisca a una chiamata di object COM di bloccare l’interfaccia utente, se viene effettuata una chiamata da un thread dell’interfaccia utente.

Un appartamento è un luogo in cui gli oggetti vivono e contengono uno o più fili. L’appartamento definisce cosa succede quando vengono fatte le chiamate. Le chiamate agli oggetti in un appartamento verranno ricevute ed elaborate su qualsiasi thread in quell’appartamento, ad eccezione del fatto che una chiamata da un thread già nell’appartamento giusto viene elaborata da sola (ovvero una chiamata diretta all’object).

I thread possono essere in un appartamento a thread singolo (nel qual caso sono l’unico thread in quell’appartamento) o in un appartamento a più thread. Specificano quale quando il thread inizializza COM per quel thread.

Lo STA è principalmente compatibile con l’interfaccia utente, che è legata a un thread specifico. Uno STA riceve notifiche di chiamate da elaborare ricevendo un messaggio finestra in una finestra nascosta; quando effettua una chiamata in uscita, avvia un ciclo di messaggi modali per impedire l’elaborazione di altri messaggi della finestra. È ansible specificare un filtro messaggi da chiamare, in modo che l’applicazione possa rispondere ad altri messaggi.

Al contrario, tutti i thread MTA condividono un singolo MTA per il processo. COM può avviare un nuovo thread di lavoro per gestire una chiamata in arrivo se non sono disponibili thread, fino a un limite di pool. I thread che effettuano le chiamate in uscita semplicemente bloccano.

Per semplicità considereremo solo gli oggetti implementati nelle DLL, che pubblicizzano nel registro ciò che supportano, impostando il valore ThreadingModel per la chiave della loro class. Ci sono quattro opzioni:

  • Filetto principale (valore ThreadingModel non presente). L’object viene creato sul thread dell’interfaccia utente principale dell’host e tutte le chiamate vengono sottoposte a marshalling su quel thread. La factory class sarà chiamata solo su quel thread.
  • Apartment Ciò indica che la class può essere eseguita su qualsiasi thread in modalità a thread singolo. Se il thread che lo crea è un thread STA, l’object verrà eseguito su quel thread, altrimenti verrà creato nello STA principale – se non esiste STA principale, verrà creato un thread STA. (Ciò significa che i thread MTA che creano gli oggetti Apartment eseguiranno il marshalling di tutte le chiamate su un thread diverso.) La factory class può essere chiamata contemporaneamente da più thread STA, quindi deve proteggere i suoi dati interni da questo.
  • Free Ciò indica una class progettata per l’esecuzione nel MTA. Verrà sempre caricato nel MTA, anche se creato da un thread STA, che significa che le chiamate del thread STA verranno sottoposte a marshalling. Questo perché un object Free è generalmente scritto con l’aspettativa che può bloccare.
  • Both Queste classi sono flessibili e caricano in qualsiasi appartamento da cui sono state create. Devono essere scritti per soddisfare entrambe le serie di requisiti, tuttavia: devono proteggere il loro stato interno da chiamate concorrenti, nel caso in cui siano caricati nel MTA, ma non devono bloccarsi, nel caso in cui siano caricati in uno STA.

Da .NET Framework, in pratica basta usare [STAThread] su qualsiasi thread che crea l’interfaccia utente. I thread di lavoro devono utilizzare il MTA, a meno che non utilizzino i componenti COM contrassegnati da Apartment , nel qual caso utilizzare lo STA per evitare problemi di sovraccarico e scalabilità del marshalling se lo stesso componente viene chiamato da più thread (poiché ogni thread dovrà attendere per il componente a sua volta). È molto più semplice in tutto se si utilizza un object COM separato per thread, indipendentemente dal fatto che il componente sia in STA o MTA.

Trovo le spiegazioni esistenti troppo gobbledygook. Ecco la mia spiegazione in inglese semplice:

STA: se un thread crea un object COM impostato su STA (quando si chiama CoCreateXXX è ansible passare un flag che imposta l’object COM in modalità STA), solo questo thread può accedere a questo object COM (questo è il significato di STA – Single Threaded Apartment ), l’altro thread che tenta di chiamare i metodi su questo object COM è nascosto in modo silenzioso trasformato in recapito di messaggi al thread che crea (possiede) l’object COM. Questo è molto simile al fatto che solo il thread che ha creato un controllo dell’interfaccia utente può accedervi direttamente. E questo meccanismo ha lo scopo di prevenire complicate operazioni di blocco / sblocco.

MTA: se un thread crea un object COM impostato su MTA, praticamente tutti i thread possono richiamare direttamente i metodi su di esso.

Questo è praticamente il succo di ciò. Sebbene tecnicamente ci siano alcuni dettagli che non ho menzionato, come nel paragrafo “STA”, il thread del creatore deve essere esso stesso STA. Ma questo è tutto ciò che devi sapere per capire STA / MTA / NA.

STA (Single Threaded Apartment) è fondamentalmente il concetto che solo una discussione interagirà con il tuo codice alla volta. Le chiamate nel tuo appartamento vengono effettuate tramite i messaggi di Windows (utilizzando una finestra non visibile). Ciò consente alle chiamate di essere accodate e attendere il completamento delle operazioni.

MTA (Multi Threaded Apartment) è il luogo in cui molti thread possono operare tutti contemporaneamente e l’onere è su di te come sviluppatore per gestire la sicurezza del thread.

C’è molto di più da imparare sul threading dei modelli in COM, ma se hai difficoltà a capire cosa sono, allora direi che capire cos’è lo STA e come funziona sarebbe il miglior punto di partenza perché la maggior parte degli oggetti COM sono gli STA.

Thread di appartamenti, se un thread risiede nello stesso appartamento dell’object utilizzato, è un thread dell’appartamento. Penso che questo sia solo un concetto COM perché è solo un modo di parlare degli oggetti e dei fili con cui interagiscono …

Ogni EXE che ospita i controlli COM o OLE definisce il suo stato appartamento. Lo stato dell’appartamento è per impostazione predefinita STA (e per la maggior parte dei programmi dovrebbe essere STA).

STA : tutti i controlli OLE per necessità devono vivere in uno STA. STA significa che l’object COM deve essere sempre manipolato sul thread dell’interfaccia utente e non può essere passato ad altri thread (proprio come qualsiasi elemento dell’interfaccia utente in MFC). Tuttavia, il tuo programma può ancora avere molti thread.

MTA : puoi manipolare l’object COM su qualsiasi thread del tuo programma.

Per quanto ne so, l”appartamento’ è usato per proteggere gli oggetti COM da problemi multi-thread.

Se un object COM non è thread-safe, dovrebbe dichiararlo come un object STA. Quindi solo il thread che lo crea può accedervi. Il thread di creazione dovrebbe dichiararsi come thread STA. Sotto il cofano, il thread memorizza le informazioni STA nel suo TLS (Thread Local Storage). Chiamiamo questo comportamento in quanto il thread entra in un appartamento STA. Quando altri thread vogliono accedere a questo object COM, deve effettuare il marshalling dell’accesso al thread di creazione. Fondamentalmente, il thread di creazione utilizza il meccanismo dei messaggi per elaborare le chiamate con restrizioni.

Se un object COM è thread-safe, dovrebbe dichiararlo come un object MTA. È ansible accedere all’object MTA tramite multi-thread.

Il codice che chiama le DLL object COM (ad esempio, per leggere i file di dati proprietari), può funzionare correttamente nell’interfaccia utente ma si blocca misteriosamente da un servizio. Il motivo è che a partire da. Le interfacce utente 2.0 Net assumono STA (thread-safe) mentre i servizi assumono MTA (prima che i servizi assumessero STA) .Dovere creare un thread STA per ogni chiamata COM in un servizio può aggiungere un sovraccarico significativo.