2015-09-12 14 views
5

Stavo facendo una ricerca ispirata a this question e ho notato che molte delle soluzioni proposte per problemi simili hanno creato un oggetto mutex durante l'inizializzazione di una variabile statica. Tale mutex funzionerà come desiderato se il thread che lo ha creato rimane attivo per tutta la vita dell'applicazione.Le variabili statiche sono inizializzate in un determinato thread?

Ora sembra ragionevole supporre che le variabili statiche siano inizializzate dal thread principale del processo e sembra anche ragionevole supporre che il thread principale del processo esca solo quando si chiude la funzione principale (presumibilmente sotto il controllo del programmatore).

Ma uno di questi è effettivamente garantito dallo standard di linguaggio C#?

PS: sto parlando di thread di Windows, non di thread .NET.

+1

L'assunzione di discussioni non è corretta. Il thread principale può uscire prima che altri thread siano finiti. C'era una domanda a riguardo [qui] (http://stackoverflow.com/questions/31128935/c-sharp-child-thread-is-still-working-even-main-thread-exit). – GolezTrol

+0

@GolezTrol: grazie. Non penso che sia di per sé fatale in questo contesto, perché in questo esempio, il thread principale esce solo perché la funzione principale esce. È sotto il controllo del programmatore, quindi possiamo semplicemente affermare che il programmatore è responsabile di non uscire dalla funzione principale fino a quando non è corretto che il mutex venga rilasciato. Ma lascia ancora la questione se lo standard della lingua assicuri che il thread principale non esca fino a quando la funzione principale non lo fa. (Domanda aggiornata di conseguenza). –

risposta

3

In C#, le variabili statiche vengono inizializzate dal programma di caricamento classe quando la classe viene caricata per la prima volta. Questo ha l'interessante artefatto di trovarsi su qualsiasi thread che ha fatto riferimento per primo alla classe.

Si noti inoltre che il thread principale non è garantito per essere un thread gestito, quindi nessuna libreria dopo il thread principale non è abbastanza sicura di essere in grado di identificarla. Ho scritto un programma una volta che non aveva thread principale dopo l'inizializzazione nativa solo per dimostrare che si poteva fare.

+0

Come sospettavo; Grazie. Ulteriori letture suggeriscono che avrei dovuto pensare non al thread principale ma al thread dell'interfaccia utente; [Ho pubblicato una risposta su questa base] (http://stackoverflow.com/a/32545751/886887) quindi se avete tempo di rivederlo rapidamente e fatemi sapere se ho fatto degli ovvi, orribili errori Si mi farebbe piacere. :-) –

+0

Il thread dell'interfaccia utente è un altro nome improprio. Puoi avere thread in UI N dove 0> = N> (numero enorme). – Joshua

+0

Intendo quello specificato da 'Application.Current.Dispatcher'; è una costante, no? Volevo chiamarlo "il thread principale dell'interfaccia utente", ma tutta la documentazione sembra chiamarla solo "il thread dell'interfaccia utente", quindi ho pensato che avrei dovuto attenermi a quello ... –

Problemi correlati