Cosa rende sicuro un metodo? Quali sono le regole?

Esistono regole / linee guida generali per ciò che rende un metodo thread-safe? Capisco che ci sono probabilmente un milione di situazioni una tantum, ma che dire in generale? È così semplice?

1. Se un metodo accede solo alle variabili locali, è thread-safe.

È così? Questo vale anche per i metodi statici?

Una risposta, fornita da @Cybis, è stata:

Le variabili locali non possono essere condivise tra i thread poiché ogni thread ottiene il proprio stack.

È il caso anche dei metodi statici?

Se un metodo viene passato a un oggetto di riferimento, ciò rompe la sicurezza del thread? Ho fatto alcune ricerche e ci sono molte cose su alcuni casi, ma speravo di essere in grado di definire, usando solo alcune regole, le linee guida da seguire per assicurarsi che un metodo sia sicuro per i thread.

Quindi, immagino che la mia ultima domanda sia: "Esiste un breve elenco di regole che definiscono un metodo thread-safe? In caso affermativo, quali sono?"

MODIFICA
Molti punti positivi sono stati fatti qui. Penso che la vera risposta a questa domanda sia: "Non ci sono regole semplici per garantire la sicurezza del thread". Freddo. Belle. Ma in generale penso che la risposta accettata fornisca un riassunto buono e breve. Ci sono sempre delle eccezioni. Così sia. Posso vivere con quello.

Se un metodo (istanza o statico) fa riferimento solo a variabili nell'ambito di tale metodo, è sicuro per i thread poiché ogni thread ha il proprio stack:

In questo caso, più thread potrebbero chiamare ThreadSafeMethodcontemporaneamente senza problemi.

public class Thing
{
    public int ThreadSafeMethod(string parameter1)
    {
        int number; // each thread will have its own variable for number.
        number = parameter1.Length;
        return number;
    }
}

Questo vale anche se il metodo chiama un altro metodo di classe che fa riferimento solo a variabili con ambito locale:

public class Thing
{
    public int ThreadSafeMethod(string parameter1)
    {
        int number;
        number = this.GetLength(parameter1);
        return number;
    }

    private int GetLength(string value)
    {
        int length = value.Length;
        return length;
    }
}

Se un metodo accede a proprietà o campi (stato oggetto) (istanza o statico), è necessario utilizzare i blocchi per assicurarsi che i valori non vengano modificati da un thread diverso.

public class Thing
{
    private string someValue; // all threads will read and write to this same field value

    public int NonThreadSafeMethod(string parameter1)
    {
        this.someValue = parameter1;

        int number;

        // Since access to someValue is not synchronised by the class, a separate thread
        // could have changed its value between this thread setting its value at the start 
        // of the method and this line reading its value.
        number = this.someValue.Length;
        return number;
    }
}

È necessario essere consapevoli del fatto che eventuali parametri passati al metodo che non sono né una struttura né immutabili potrebbero essere mutati da un altro thread al di fuori dell'ambito del metodo.

Per garantire la corretta concorrenza è necessario utilizzare il blocco.

per ulteriori informazioni consultare l' istruzione lock C # reference e ReadWriterLockSlim .

lock è principalmente utile per fornire una funzionalità alla volta,
ReadWriterLockSlimè utile se hai bisogno di più lettori e singoli autori.

Se un metodo accede solo alle variabili locali, è thread-safe. È così?

Assolutamente no. È possibile scrivere un programma con una sola variabile locale a cui si accede da un singolo thread che tuttavia non è thread-safe:

https://stackoverflow.com/a/8883117/88656

Questo vale anche per i metodi statici?

Assolutamente no.

Una risposta, fornita da @Cybis, è stata: "Le variabili locali non possono essere condivise tra i thread perché ogni thread ottiene il proprio stack".

Assolutamente no. La caratteristica distintiva di una variabile locale è che è visibile solo dall'ambito locale , non che è allocata nel pool temporaneo . È perfettamente legale e possibile accedere alla stessa variabile locale da due thread diversi. Puoi farlo usando metodi anonimi, lambda, blocchi iteratori o metodi asincroni.

È il caso anche dei metodi statici?

Assolutamente no.

Se un metodo viene passato a un oggetto di riferimento, ciò rompe la sicurezza del thread?

Può essere.

Ho fatto alcune ricerche e ci sono molte cose su alcuni casi, ma speravo di essere in grado di definire, usando solo alcune regole, le linee guida da seguire per assicurarsi che un metodo sia sicuro per i thread.

Dovrai imparare a vivere con delusione. Questo è un argomento molto difficile.

Quindi, immagino che la mia ultima domanda sia: "Esiste un breve elenco di regole che definiscono un metodo thread-safe?

No. Come hai visto dal mio esempio in precedenza, un metodo vuoto può essere non thread-safe . Potresti anche chiedere "c'è un breve elenco di regole che garantisce che un metodo sia corretto ". No non c'è. La sicurezza del filo non è altro che un tipo estremamente complicato di correttezza.

Inoltre, il fatto che tu stia ponendo la domanda indica il tuo fondamentale fraintendimento sulla sicurezza del thread. La sicurezza del thread è una proprietà globale , non locale di un programma. Il motivo per cui è così difficile ottenere il giusto risultato è che devi avere una conoscenza completa del comportamento di threading dell'intero programma al fine di garantirne la sicurezza.

Ancora una volta, guarda il mio esempio: ogni metodo è banale . È il modo in cui i metodi interagiscono tra loro a livello "globale" che rende il deadlock del programma. Non puoi guardare ogni metodo e selezionarlo come "sicuro" e quindi aspettarti che l'intero programma sia sicuro, non più di quanto tu possa concludere che poiché la tua casa è fatta di mattoni al 100% non vuoti che la casa è anche non cavo. La cavità di una casa è una proprietà globale dell'intera cosa, non un aggregato delle proprietà delle sue parti.

Non c'è una regola dura e veloce.

Ecco alcune regole per rendere sicuro il thread di codice in .NET e perché queste non sono buone regole:

1. La funzione e tutte le funzioni che chiama devono essere pure (senza effetti collaterali) e utilizzare variabili locali. Anche se questo renderà il tuo thread sicuro per il codice, ci sono anche pochissime cose interessanti che puoi fare con questa limitazione in .NET.
2. Ogni funzione che opera su un oggetto comune deve avere lockuna cosa comune. Tutti i blocchi devono essere eseguiti nello stesso ordine. Ciò renderà sicuro il thread del codice, ma sarà incredibilmente lento e potresti anche non utilizzare più thread.
3. ...

Non esiste una regola che renda sicuro il thread di codice, l'unica cosa che puoi fare è assicurarti che il tuo codice funzionerà indipendentemente da quante volte viene eseguito attivamente, ogni thread può essere interrotto in qualsiasi momento, con ogni thread in il proprio stato / posizione e questo per ogni funzione (statica o di altro tipo) che accede a oggetti comuni.

Deve essere sincronizzato, usando un blocco oggetto, senza stato o immutabile.

link: http://docs.oracle.com/javase/tutorial/essential/concurrency/immutable.html