Синхронизация потоков WinAPI. Основы

@codesurfer · Регистрация: 09.02.2017

Author24 — интернет-сервис помощи студентам

Всем привет.

Пример.

C++

class A {
private:
   volatile LONG value = 0;
   
public:
   
   void set(const LONG newValue) {
      InterlockedExchange(&value, newValue);
   }
 
   LONG get() {
      return value;
   }    
};

Вопрос 1.
Безопасен ли метод get() для многопоточного приложения?

Другими словами, может ли быть ситуация, при которой Поток1 методом get() считает 16 байт из value, в этот момент Поток2 методом set() заменит значение value на новое, и Поток1 считает оставшиеся 16 байт но уже из нового значения value?

Тот же вопрос, но если вместо типа LONG будет например string. Как тогда будет происходить считывание?
Понятно, что внутри set() будет использоваться другой тип синхронизации вместо InterlockedExchange.

Вопрос 2.
Чем Вы обычно синхронизируете доступ: критической секцией или SRWLock?
Если критической секцией, то со спин-блокировкой или без?

Вопрос 3.
Как правильно прикинуть подходящее кол-во циклов спин блокировки?

Убежденный · 02.08.2017, 20:05

Сообщение от codesurfer

Другими словами, может ли быть ситуация, при которой Поток1 методом get() считает 16 байт из value, в этот момент Поток2 методом set() заменит значение value на новое, и Поток1 считает оставшиеся 16 байт но уже из нового значения value?

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

Сообщение от codesurfer

Тот же вопрос, но если вместо типа LONG будет например string. Как тогда будет происходить считывание?

Со string такой номер уже не пройдет, нужен объект синхронизации.

Сообщение от codesurfer

Чем Вы обычно синхронизируете доступ: критической секцией или SRWLock?

Очень сильно зависит от того, что именно нужно синхронизировать.
Единого рецепта нет.

Сообщение от codesurfer

Как правильно прикинуть подходящее кол-во циклов спин блокировки?

Лучше не заморачиваться такими вещами до тех пор, пока сильно не прижмет и
пока лишними 20-30 циклами ты не сможешь вырвать какой-то реальный прирост.
Я программирую на Win32 API несколько лет и ни разу, наверное, мне не потребовалось
использовать критическую секцию с явным заданием счетчика спин-блокировок.

А вот думать над правильной архитектурой распараллеливания, - а это намного важнее, -
приходится намного чаще...

@codesurfer · 03.08.2017, 00:56 **[ТС]**

Убежденный, с возвращением! Сейчас август - время отпусков. Смотрю никто не отвечает, подумал в отпуск все разбежались...

Сообщение от Убежденный

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

Сообщение от Убежденный

Со string такой номер уже не пройдет, нужен объект синхронизации.

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

Сообщение от Убежденный

Лучше не заморачиваться такими вещами до тех пор, пока сильно не прижмет и
пока лишними 20-30 циклами ты не сможешь вырвать какой-то реальный прирост.
Я программирую на Win32 API несколько лет и ни разу, наверное, мне не потребовалось
использовать критическую секцию с явным заданием счетчика спин-блокировок.

Понятно, спин-блокировки – в печку.

Сообщение от Убежденный

А вот думать над правильной архитектурой распараллеливания, - а это намного важнее, - приходится намного чаще...

Тоже понятно.

Сообщение от Убежденный

Очень сильно зависит от того, что именно нужно синхронизировать. Единого рецепта нет.

Тут не понятно. Я думал отличие SRWLock от критической секции заключается только в том, что SRWLock делит обращение потоков на две категории: запись и чтение;
Запись - только один пишущий поток получает монополию на ресурс.
Чтение – все читающие потоки совместно допускаются к ресурсу.
А критическая секция всегда даёт монополию на ресурс только одному потку, и для чтения и для записи. И у SRWLock есть ряд ограничений:
1. Ограничение на рекурсивное использование.
* Можно пережить. Мне как-то вообще не довелось использовать рекурсию.
2. Нет аналога TryEnter().
* Но я так понимаю, завёрнутый в класс SRWLock с флагами входа/выхода в блокировку запросто даёт этот аналог.
3. Нет необходимости уничтожения объекта SRWLock.
* Тем лучше.
4. На уровне системы, SRWLock в чём-то не учитываются (как вечно-зависший объект кажется). А критические секции системой учитываются. Как-то так, точно не помню.
* Тоже допустимо.

Итого – SRWLock практически везде выигрывает. Тогда, где есть место для критической секции на фоне всех преимуществ SRWLock?

@codesurfer · 04.08.2017, 16:50 **[ТС]**

Сообщение от codesurfer

2. Нет аналога TryEnter().

Кстати, SRWLock уже тоже обзавелись Try-функциями.

Убежденный · 05.08.2017, 15:33

Сообщение от codesurfer

Я думал отличие SRWLock от критической секции заключается только в том, что SRWLock делит обращение потоков на две категории: запись и чтение;
Запись - только один пишущий поток получает монополию на ресурс.
Чтение – все читающие потоки совместно допускаются к ресурсу.
А критическая секция всегда даёт монополию на ресурс только одному потку, и для чтения и для записи.

Ну все верно, разные объекты с разными свойствами. Из этого вовсе не следует,
что первый лучше или хуже второго. Они просто разные, для разных целей.
Например, если у тебя данные требуют только эксклюзивного доступа в один момент времени,
то никакого смысла в использовании SRWLock нету. Да и на невысокой конкуренции
принципиальной разницы между SRWLock и критической секцией ты не получишь.

@codesurfer · 05.08.2017, 19:53 **[ТС]**

Понятно, спасибо.

Убежденный Ушел с форума 16473 / 7436 / 1187 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	02.08.2017, 20:05	2
	Сообщение от codesurfer Другими словами, может ли быть ситуация, при которой Поток1 методом get() считает 16 байт из value, в этот момент Поток2 методом set() заменит значение value на новое, и Поток1 считает оставшиеся 16 байт но уже из нового значения value? В данном примере - безопасен. При условии, что твой тип не больше sizeof (size_t) и что он размещен по выравненному адресу (об этом обычно заботится компилятор при генерации соответствующего кода). Сообщение от codesurfer Тот же вопрос, но если вместо типа LONG будет например string. Как тогда будет происходить считывание? Со string такой номер уже не пройдет, нужен объект синхронизации. Сообщение от codesurfer Чем Вы обычно синхронизируете доступ: критической секцией или SRWLock? Очень сильно зависит от того, что именно нужно синхронизировать. Единого рецепта нет. Сообщение от codesurfer Как правильно прикинуть подходящее кол-во циклов спин блокировки? Лучше не заморачиваться такими вещами до тех пор, пока сильно не прижмет и пока лишними 20-30 циклами ты не сможешь вырвать какой-то реальный прирост. Я программирую на Win32 API несколько лет и ни разу, наверное, мне не потребовалось использовать критическую секцию с явным заданием счетчика спин-блокировок. А вот думать над правильной архитектурой распараллеливания, - а это намного важнее, - приходится намного чаще... 0

@codesurfer 0 / 0 / 0 Регистрация: 09.02.2017 Сообщений: 69
	03.08.2017, 00:56 [ТС]	3
	Убежденный, с возвращением! Сейчас август - время отпусков. Смотрю никто не отвечает, подумал в отпуск все разбежались... Сообщение от Убежденный В данном примере - безопасен. При условии, что твой тип не больше sizeof (size_t) и что он размещен по выравненному адресу (об этом обычно заботится компилятор при генерации соответствующего кода). Сообщение от Убежденный Со string такой номер уже не пройдет, нужен объект синхронизации. Из сказанного я делаю вывод, что начинающему лучше не играться с этими тонкостями, а тупо синхронизировать всё, и запись и чтение. Критически на скорости это не скажется, но зато точно будет надёжно, а дальше, по мере обретения опыта, уже смотреть. Сообщение от Убежденный Лучше не заморачиваться такими вещами до тех пор, пока сильно не прижмет и пока лишними 20-30 циклами ты не сможешь вырвать какой-то реальный прирост. Я программирую на Win32 API несколько лет и ни разу, наверное, мне не потребовалось использовать критическую секцию с явным заданием счетчика спин-блокировок. Понятно, спин-блокировки – в печку. Сообщение от Убежденный А вот думать над правильной архитектурой распараллеливания, - а это намного важнее, - приходится намного чаще... Тоже понятно. Сообщение от Убежденный Очень сильно зависит от того, что именно нужно синхронизировать. Единого рецепта нет. Тут не понятно. Я думал отличие SRWLock от критической секции заключается только в том, что SRWLock делит обращение потоков на две категории: запись и чтение; Запись - только один пишущий поток получает монополию на ресурс. Чтение – все читающие потоки совместно допускаются к ресурсу. А критическая секция всегда даёт монополию на ресурс только одному потку, и для чтения и для записи. И у SRWLock есть ряд ограничений: 1. Ограничение на рекурсивное использование. * Можно пережить. Мне как-то вообще не довелось использовать рекурсию. 2. Нет аналога TryEnter(). * Но я так понимаю, завёрнутый в класс SRWLock с флагами входа/выхода в блокировку запросто даёт этот аналог. 3. Нет необходимости уничтожения объекта SRWLock. * Тем лучше. 4. На уровне системы, SRWLock в чём-то не учитываются (как вечно-зависший объект кажется). А критические секции системой учитываются. Как-то так, точно не помню. * Тоже допустимо. Итого – SRWLock практически везде выигрывает. Тогда, где есть место для критической секции на фоне всех преимуществ SRWLock? 0

@codesurfer 0 / 0 / 0 Регистрация: 09.02.2017 Сообщений: 69
	04.08.2017, 16:50 [ТС]	4
	Сообщение от codesurfer 2. Нет аналога TryEnter(). Кстати, SRWLock уже тоже обзавелись Try-функциями. 0

Убежденный Ушел с форума 16473 / 7436 / 1187 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	05.08.2017, 15:33	5
	Сообщение от codesurfer Я думал отличие SRWLock от критической секции заключается только в том, что SRWLock делит обращение потоков на две категории: запись и чтение; Запись - только один пишущий поток получает монополию на ресурс. Чтение – все читающие потоки совместно допускаются к ресурсу. А критическая секция всегда даёт монополию на ресурс только одному потку, и для чтения и для записи. Ну все верно, разные объекты с разными свойствами. Из этого вовсе не следует, что первый лучше или хуже второго. Они просто разные, для разных целей. Например, если у тебя данные требуют только эксклюзивного доступа в один момент времени, то никакого смысла в использовании SRWLock нету. Да и на невысокой конкуренции принципиальной разницы между SRWLock и критической секцией ты не получишь. 0

@codesurfer 0 / 0 / 0 Регистрация: 09.02.2017 Сообщений: 69
	05.08.2017, 19:53 [ТС]	6
	Понятно, спасибо. 0