È male usare le variabili di classe in un'app multithread?

Question

Ho ereditato un progetto che deve essere sottoposto a mutithreading. Esistono tre classi principali che vengono utilizzate nei thread di lavoro.

BASE CLASS - ha un livello di classe SqlDataAdapter e DataTable. CLASSE UNITA EREDITA - Utilizza SqlDataAdapter e DataTable ereditati. SECONDA CLASSE DUE: utilizza SqlDataAdapter e DataTable ereditati.

Tutto funziona perfettamente, ma ho solo due utenti che testano contemporaneamente.

Avere SqlDataAdapter e DataTable essere variabili a livello di classe è una cattiva idea?

Aggiorna Mi dispiace è un SqlDataAdapter non un SqlTableAdapter. La lingua è C #. SqlDataAdapter e DataTable provengono dallo spazio dei nomi System.Data.SqlClient.

Ecco alcuni della classe base:

public abstract class BaseSync
{
    #region Variables
    internal SqlDataAdapter stageDataAdapter;
    internal DataTable stageDataTable;
    #endregion //Variables
}

Parte seconda

Esiste anche una classe di utilità singleton utilizzata da tutte le classi derivate. Non so se causerà problemi o no. Sembra così:

public class Utility
{ 
    private static readonly Utility _utility= new Utility();

    private Utility()
    { }

    public static Utility GetUtility()
    {
        return _utility;
    }

    public int GetAutoNumber(string tablename, string fieldname, string siteId)
    {
        string _tablename = tablename;
        string _fieldname = fieldname;
        ...
    }

    internal MissingInfo NormalizeRow(DataRow dataRow)
    {

        MissingInfo retVal = MissingInfo.None;

        //Num
        if (dataRow["Num"] == DBNull.Value)
        {
           retVal =MissingInfo.Num;
           dataRow["Num"] = 1;
        }
        ...
    }
}

Answer 1

Questo dipende dal livello di accesso degli oggetti. Purché non siano statici (condivisi in VB.NET). Dovresti andare bene ad averli nell'oggetto, purché ogni thread abbia la sua istanza dell'oggetto.

Dove ti trovi in ??situazioni interessanti sono i membri statici che sono condivisi in tutte le istanze.

Quindi, in sostanza, dovremmo vedere il codice.

Answer 2

Far modificare le variabili da thread diversi senza sincronizzazione è sempre una idea davvero negativa .

Non dici se questo è il caso però. Se esegui il thread, devi pianificare e verificare cosa stai facendo.

Answer 3

La regola delle variabili è che maggiore è il numero di luoghi da cui potrebbero potenzialmente cambiare, maggiori sono le possibilità di condizioni di gara, soprattutto se l'applicazione si evolve.

Non ci sono molte informazioni nella tua domanda, quindi è difficile fornire una risposta specifica. Le variabili a livello di classe (se pubbliche) possono spesso essere trattate come variabili globali e sono quindi accessibili da qualsiasi luogo, aumentando il rischio di corruzione.

Un possibile approccio potrebbe essere quello di nascondere questi campi e fornire l'accesso tramite funzioni a livello di classe. Puoi quindi fare più cose perché hai creato punti di accesso specifici a queste variabili. Dovresti stare attento a non dare mai alle applicazioni riferimenti diretti e mutabili a quell'oggetto, il che potrebbe richiedere una riscrittura, ma renderebbe il tuo programma più sicuro.

Answer 4

dovresti sempre considerare di fare la sincronizzazione quando condividi oggetti non costanti in multi-thread, altrimenti un giorno finirai per rovinare ...

quindi, va bene se vuoi renderlo una variabile di classe, ma ricorda di creare un meccanismo di blocco per esso.