Est-il mauvais d'utiliser des variables de classe dans une application multithread?

Question

J'ai hérité d'un projet qui doit être multithread. Trois classes principales sont utilisées dans les threads de travail.

BASE CLASS - a un niveau de classe SqlDataAdapter et DataTable. INHERITED CLASS ONE - Utilise les SqlDataAdapter et DataTable hérités. HERHERITED CLASS TWO - Utilise les SqlDataAdapter et DataTable hérités.

Tout semble fonctionner, mais je n'ai que deux utilisateurs à tester en même temps.

Est-ce une mauvaise idée d’avoir les variables de niveau classe SqlDataAdapter et DataTable?

Mettre à jour Désolé, il s'agit d'un SqlDataAdapter et non d'un SqlTableAdapter. La langue est C #. SqlDataAdapter et DataTable proviennent de l'espace de noms System.Data.SqlClient.

Voici quelques exemples de la classe de base:

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

Deuxième partie

Il existe également une classe d’utilitaire singleton que toutes les classes dérivées utilisent. Je ne sais pas si cela causera des problèmes ou non. Cela ressemble à ceci:

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

Cela dépend du niveau d'accès des objets. Tant qu'ils ne sont pas statiques (partagés dans VB.NET). Vous devriez pouvoir les avoir dans l'objet, à condition que chaque thread ait sa propre instance de l'objet.

Les membres statiques partagés par toutes les instances sont des situations intéressantes.

En résumé, nous aurions besoin de voir le code.

Answer 2

Avoir des variables modifiées par différents threads sans synchronisation est toujours une très mauvaise idée .

Vous ne mentionnez pas si c'est le cas cependant. Si vous enfilez un fil, vous devez planifier et vérifier ce que vous faites.

Answer 3

La règle à propos des variables est que plus elles peuvent potentiellement changer d'endroits, plus il y a de chances que des conditions de concurrence soient présentes, en particulier si l'application évolue.

Il n’ya pas beaucoup d’informations dans votre question, il est donc difficile de donner une réponse précise. Les variables au niveau de la classe (si elles sont publiques) peuvent souvent être traitées comme des variables globales et sont donc accessibles de partout, ce qui augmente le risque de corruption.

Une approche possible pourrait consister à masquer ces champs et à fournir un accès via des fonctions de niveau classe. Vous pouvez alors faire plus de choses parce que vous avez créé des points d’accès spécifiques à ces variables. Vous devez veiller à ne jamais donner aux applications de références directes et modifiables à cet objet, ce qui peut nécessiter une réécriture, mais cela rendrait votre programme plus sûr.

Answer 4

vous devriez toujours envisager de faire la synchronisation lorsque vous partagez des objets non constants en multi-thread, sinon vous finirez par être foutus un jour ...

Donc, si vous voulez en faire une variable de classe, faites-le avec un mécanisme de verrouillage.