Требует ли синхронизации обращение к статическим полям класса, имеющим значимый тип?

Question

[simply_user]

Здравствуйте!
Имеется следующий класс:

public static class ReadyUpload
    {
        public static bool filesRead;
        public static bool readAtLeastOneFile;
        public static bool listsReceived;
        public static bool excelIsRunning;

        public static bool CheckReadyUpload()
        {
           
        }
    }

Поля будут меняться в одной задаче, читаться - в другой, внутри метода CheckReadyUpload. Вопрос: нужно ли использовать какие-либо блокировки при записи и чтении?
Заранее спасибо.

Answer 1

[lam0x86]

Блокировки не нужны. Но просто так записывать и читать поля из разных потоков тоже нельзя.
Вот смотрите: предположим, у вас многопроцессорная система. Один поток выполняется на одном процессоре, другой - на другом. У обоих процессоров есть свой кэш (точнее, несколько уровней кэшей). Если первый поток изменяет переменные (не важно, статические они или нет), то они не попадут в оперативную память до тех пор, пока процессор не сбросит кэш при помощи специальной инструкции. Поэтому, второй поток будет продолжать думать, что данные не изменились.
Для того, чтобы процессоры правильно работали с такими общими переменными придуманы барьеры памяти (memory barriers). Есть несколько способов поставить такие барьеры:
1) методы Thread.MemoryBarrier() / Thread.VolatileRead() / Thread.VolatileWrite()
2) добавить к полю модификатор volatile
3) использовать методы класса Interlocked
4) Использование блокирующих примитивов синхронизации (Monitor, ReaderWriterLockSlim, Events, Semaphores, Mutexes, etc.)

Без контекста задачи не ясно, что вам подойдёт в вашей задаче, но похоже, что достаточно пометить поля модификатором volatile.

Comments

[simply_user]

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

public static class ReadyUpload
{
static bool filesRead, readAtLeastOneFile, listsReceived, excelIsRunning;

public static bool FilesRead
{
get
{
bool tmp;
object lockObj = new object();
Monitor.Enter(lockObj);
tmp = filesRead;
Monitor.Exit(lockObj);
return tmp;
}
set
{
object lockObj = new object();
Monitor.Enter(lockObj);
filesRead = value;
Monitor.Exit(lockObj);
}
}

//...

public static bool CheckReadyUpload()
{
object lockObj = new object();
Monitor.Enter(lockObj);
//...
Monitor.Exit(lockObj);
}
}

[lam0x86]

Так работать не будет. Вы на каждое чтение и запись создаёте новый объект синхронизации, а идея блокировок как раз в том, чтобы объект синхронизации был один. Либо по одному объекту на каждое поле класса, чтобы можно было менять (или читать) разные поля одновременно из нескольких потоков, что, похоже, не ваш случай - у вас всего два потока - один меняет, другой читает. Поэтому можно синхронизироваться на одном объекте. Вам нужно один раз создать статическое поле "private static object lockObj = new object();" внутри класса и использовать его во всех методах. Но вообще говоря, как я уже сказал, в вашем случае можно вообще обойтись без блокировок и использовать volatile.
Кстати, вы неправильно используете Monitor. Правильно - так:
try
{
Monitor.Enter(lockObj);
...
}
finally
{
Monitor.Exit(lockObj);
}

А еще лучше - использовать ключевое слово lock - это на самом деле синтаксический сахар над Monitor-ом, который как раз и делает то, что я написал выше.

[simply_user]

lam0x86: Спасибо, но мой случай как раз вот этот: "Либо по одному объекту на каждое поле класса, чтобы можно было менять (или читать) разные поля одновременно из нескольких потоков". Каждое поле в этом классе изменяется в своей задаче (кроме readAtLeastOneFile, она меняется там же где и filesRead), поэтому одну переменную для блокирования использовать нельзя, но, как я теперь понимаю, нельзя использовать и отдельные переменные для get и set. Тогда получается, что ещё одна переменная для синхронизации в методе CheckReadyUpload() не нужна.

Итак, одна переменная для синхронизации на каждое поле класса, а в методе CheckReadyUpload переменную lockObj я уберу, но к полям класса я буду обращаться в методе, как и везде, через свойства.

Таким образом, класс будет выглядеть вот так:
public static class ReadyUpload
{
static readonly object lockFilesRead = new object();
static bool filesRead;
//Остальные поля убраны для краткости.

public static bool FilesRead
{
get
{
bool tmp;
lock (lockFilesRead)
{
tmp = filesRead;
}
return tmp;
}
set
{
lock (lockFilesRead)
{
filesRead = value;
}
}
}

public static bool CheckReadyUpload()
{
if (FilesRead)
{

}
//...
}
}
Поправьте меня, пожалуйста, если я не прав.

[lam0x86]

simply_user: всё правильно, можно и так, как вы написали (переменную tmp можно убрать и писать return прямо внутри lock). Но я считаю, в вашем случае ввод разных объектов - это преждевременная оптимизация, которая только усложняет читаемость, но даёт, скорее всего, минимальный прирост производительности. Если уж вы не хотите использовать volatile, я бы посоветовал просто пометить все методы класса атрибутом [MethodImpl(Synchronized)]. Это то же самое, что lock с общим объектом синхронизации, только объектом в данном случае будет являться сам класс.

Answer 2

[Виталий Пухов]

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

Comments

[simply_user]

Спасибо.