Thread safe

di il
4 risposte

Thread safe

Ciao a tutti, vi disturbo per farvi un'altra domanda sulla safe di questo scenario.

Scenario : nella classe A ci sono diversi task che girano dentro un metodo "Pippo". Prima di dare lo start ad ogni task viene creato al volo un nuovo oggetto (object obj = new object();) che poi verrà passato come parametro a "Pippo";

Ad un certo punto, questi task chiamano il metodo "Pluto" sempre della classe A.

Nel metodo "Pluto" si accede al membro di classe A "view", istanza di un'altra classe B; vi si accede facendo una chiamata ad un suo metodo pubblico view.myMetod(boll param1, string param2, object param3)

Il metodo "Pluto" non presenta meccanismi di lock, ma tuttavia esso è presente come prima istruzione nel metodo view.myMetod(boll param1, string param2, object param3.....);

La mia domanda è : posso affermare di essere in una condizione di thread safety ?

Grazie.

La classe "A", la classe "B", le chiamate e gli oggetti

public class A: IControllerSetup
{
   private IViewStation _view;

   public void Start() // 

     { //facciamo finta di avere una lista di 
        Task e per ogni task

       object myobj = new object();

       Task.Run(()=>Pippo(myobj))

     }

   public void Pippo(object MyObj)
   {
     //...some code here

     Pluto(MyObj);
   }
}



private void Pluto (object myObj)
{
   //some code here
    object prova = new object();
   _view.MyMetod("xxxx",false,false,prova, myObj);


}

public class B
{

   private static object readonly locker = new object();

   public void MyMetod(string testo,bool p, bool t, object 
   obj1, object obj2)
   {
     lock(locker)
     //...some code here
   }
}

4 Risposte

  • Re: Thread safe

    Che cosa e' la 'thread safety'?

    Comunque, l'accesso concorrente a risorsa richiede una sincronizzazione MA non sempre

    SE tutti i tread devono SOLO leggere, e non ci sono modifiche, non serve nessun lock

    SE ci sono tanti thread che leggono ed uno solo che scrive (o pochissimi) ti serve un 'read/write lock'

    SE tutti leggono e scrivono, ti serve un 'mutex'.

    SE tutti leggono e scrivono su un'istanza DIVERSA di un oggett, NON TI SERVE NESSUN lock.

    Per come hai scritto il codice, NESSUNO fa modifiche, QUINDI il lock non ti serve.

    L'uso di oggetti di sincronizzazione va fatto 'per effettivi' motivi di sincronizzazione, ed in modo moooolto occulato.
    Non va bene NE metterne troppo pochi, NE metterne troppi.
    E con due o piu', rischi 'l' abbraccio mortale' (dead lock).
  • Re: Thread safe

    markolino ha scritto:


    Ciao a tutti, vi disturbo per farvi un'altra domanda sulla safe di questo scenario.
    [...]
    La mia domanda è : posso affermare di essere in una condizione di thread safety ?
    Hai dettagliato le chiamate, con nomi un po' fuorvianti, ma non hai descritto ciò che avviene all'interno di quei metodi.
    Ad esempio, vi sono metodi che cambiano lo stato di un oggetto?
    Quei metodi possono essere all'occorrenza (potenzialmente) resi static?

    La condizione di thread safe non dipende dallo stack delle chiamate, ma da cosa fanno le chiamate in sé.
    Prova a spiegare meglio lo scenario di contorno, magari sostituendo i nomi con qualcosa di più comprensibile rispetto ad "A", "B", "Pippo" e "Pluto".

    Ciao!
  • Re: Thread safe

    migliorabile ha scritto:


    Che cosa e' la 'thread safety'?

    Comunque, l'accesso concorrente a risorsa richiede una sincronizzazione MA non sempre

    SE tutti i tread devono SOLO leggere, e non ci sono modifiche, non serve nessun lock

    SE ci sono tanti thread che leggono ed uno solo che scrive (o pochissimi) ti serve un 'read/write lock'

    SE tutti leggono e scrivono, ti serve un 'mutex'.

    SE tutti leggono e scrivono su un'istanza DIVERSA di un oggett, NON TI SERVE NESSUN lock.

    Per come hai scritto il codice, NESSUNO fa modifiche, QUINDI il lock non ti serve.

    L'uso di oggetti di sincronizzazione va fatto 'per effettivi' motivi di sincronizzazione, ed in modo moooolto occulato.
    Non va bene NE metterne troppo pochi, NE metterne troppi.
    E con due o piu', rischi 'l' abbraccio mortale' (dead lock).
    Ok grazie.
  • Re: Thread safe

    Alka ha scritto:


    markolino ha scritto:


    Ciao a tutti, vi disturbo per farvi un'altra domanda sulla safe di questo scenario.
    [...]
    La mia domanda è : posso affermare di essere in una condizione di thread safety ?
    Hai dettagliato le chiamate, con nomi un po' fuorvianti, ma non hai descritto ciò che avviene all'interno di quei metodi.
    Ad esempio, vi sono metodi che cambiano lo stato di un oggetto?
    Quei metodi possono essere all'occorrenza (potenzialmente) resi static?

    La condizione di thread safe non dipende dallo stack delle chiamate, ma da cosa fanno le chiamate in sé.
    Prova a spiegare meglio lo scenario di contorno, magari sostituendo i nomi con qualcosa di più comprensibile rispetto ad "A", "B", "Pippo" e "Pluto".

    Ciao!
    Grazie Alka per la risposta. Dai sono nomi simpatici
    All'interno dei metodi NON ci sono oggeti condivisi, le modifiche vengono applicate nel metodo MyMetod della classe "B" a cui i task accedono tramite il membro condiviso "_view" della classe "A". Pertanto il lock si trova dentro tale metodo.

    All'interno invece del metodo "Pippo" di classe "A" i task svolgono operazioni sull'oggetto passato come parametro ( object MyObj) per esempio usando qualche suo metodo (esempio scrivere un file .txt) ma è un oggetto diverso per ogni task quindi non dovrebbero esserci problemi.
Devi accedere o registrarti per scrivere nel forum
4 risposte