Разве плохо использовать переменные класса в многопоточном приложении?

Question

Я унаследовал проект, который должен быть многопоточным. В рабочих потоках используются три основных класса.

BASE CLASS - имеет уровень класса SqlDataAdapter и DataTable. Унаследованный класс один - использует унаследованные SqlDataAdapter и DataTable. Унаследованный второй класс - использует унаследованные SqlDataAdapter и DataTable.

Все работает, но у меня одновременно тестируют только два пользователя.

Является ли SqlDataAdapter и DataTable переменными уровня класса - плохая идея?

Обновление Извините, это SqlDataAdapter, а не SqlTableAdapter. Язык C #. SqlDataAdapter и DataTable взяты из пространства имен System.Data.SqlClient.

Вот некоторые из базового класса:

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

Часть вторая

Существует также одноэлементный служебный класс, который используют все производные классы. Я не знаю, вызовет ли это проблемы или нет. Это выглядит так:

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

Это зависит от уровня доступа объектов. Пока они не являются статическими (Shared в VB.NET). Вам должно быть хорошо иметь их в объекте, если каждый поток имеет свой собственный экземпляр объекта.

Где вы попадаете в интересные ситуации, со статическими членами, которые являются общими для всех экземпляров.

Так что, в общем и целом, нам нужно увидеть код.

Answer 2

Правило, касающееся переменных, заключается в том, что чем больше мест они могут изменить, тем больше шансов для состояния гонки, особенно если приложение развивается.

В вашем вопросе мало информации, поэтому сложно дать конкретный ответ. Переменные уровня класса (если они общедоступны) часто можно рассматривать как глобальные переменные, и поэтому они доступны везде, что повышает риск коррупции.

Возможный подход может заключаться в том, чтобы скрыть эти поля и обеспечить доступ через функции уровня класса. Затем вы можете делать больше вещей, потому что вы создали определенные точки доступа к этим переменным. Вы должны быть осторожны, чтобы никогда не давать приложениям прямые и изменяемые ссылки на этот объект, что может потребовать некоторого переписывания, но это сделает вашу программу более безопасной.

Answer 3

Переменные, измененные разными потоками без синхронизации, всегда являются очень плохой идеей .

Вы не упоминаете, если это так. Если вы нить, вам нужно планировать и проверять, что вы делаете.

Answer 4

вы всегда должны учитывать синхронизацию при совместном использовании неконстантных объектов в многопоточности, иначе вы когда-нибудь облажаетесь ...

Итак, все в порядке, если вы хотите сделать его переменной класса, но не забудьте сделать для него какой-нибудь механизм блокировки.