¿Es malo usar variables de clase en una aplicación multiproceso?

Question

Heredé un proyecto que necesita ser multiproceso. Hay tres clases principales que se utilizan en los subprocesos de trabajo.

CLASE BASE: tiene un nivel de clase SqlDataAdapter y DataTable. HERENCIA DE CLASE UNO: utiliza el SqlDataAdapter y DataTable heredados. HERENCIA CLASE DOS: utiliza el SqlDataAdapter y DataTable heredados.

Todo funciona al mismo tiempo, pero solo tengo dos usuarios probando al mismo tiempo.

¿Es una mala idea tener SqlDataAdapter y DataTable como variables de nivel de clase?

Actualizar Lo siento, es un SqlDataAdapter no un SqlTableAdapter. El lenguaje es C #. El SqlDataAdapter y DataTable son del espacio de nombres System.Data.SqlClient.

Aquí está una parte de la clase base:

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

Parte dos

También hay una clase de utilidad singleton que utilizan todas las clases derivadas. No sé si causará problemas o no. Se parece a esto:

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

Esto depende del nivel de acceso de los objetos. Mientras no sean estáticos (compartidos en VB.NET). Debería estar bien tenerlos en el objeto, siempre que cada hilo tenga su propia instancia del objeto.

Donde te encuentras en situaciones interesantes son los miembros estáticos que se comparten en todas las instancias.

Por lo tanto, lo largo y corto es que necesitaríamos ver el código.

Answer 2

Tener variables modificadas por diferentes hilos sin sincronización es siempre una muy mala idea .

Sin embargo, no mencionas si este es el caso. Si lo roscas, necesitas planear y verificar lo que estás haciendo.

Answer 3

La regla sobre las variables es que cuanto más lugares puedan cambiar, más posibilidades hay de condiciones de carrera, especialmente si la aplicación evoluciona.

No hay mucha información en su pregunta, por lo que es difícil proporcionar una respuesta específica. Las variables de nivel de clase (si son públicas) a menudo pueden tratarse como variables globales y, por lo tanto, son accesibles desde cualquier parte, lo que aumenta el riesgo de corrupción.

Un posible enfoque podría ser ocultar estos campos y proporcionar acceso a través de funciones de nivel de clase. Luego puede hacer más cosas porque ha creado puntos específicos de acceso a estas variables. Deberá tener cuidado para asegurarse de que nunca le está dando a las aplicaciones una referencia directa y mutable a ese objeto, lo que puede requerir una reescritura, pero eso haría que su programa sea más seguro.

Answer 4

siempre debes considerar hacer una sincronización cuando compartes objetos no constantes en multihilo, de lo contrario terminarás arruinado algún día ...

entonces, está bien si quieres convertirla en una variable de clase, pero recuerda hacer algún mecanismo de bloqueo para ella.