Реестр Win32 "потокобезопасен"?

Если у меня есть два процесса доступа к определенному ключу реестра (отключен от HKLM), полезно ли обернуть логику в Mutex?

Ответ 1

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

Однако, если у вас одновременно есть несколько процессов/потоков, обращающихся к реестру, он не дает никаких гарантий относительно того, что происходит в первую очередь. Только то, что вы не получите искаженные данные.

Изменить: Дальнейшее чтение, см. Невозможность заблокировать кого-то из реестра - это функция, а не ошибка.

Ответ 2

Как отмечали другие, отдельные операции являются атомарными. Если вам нужно сделать больший набор операций атомарным, и вы ориентируетесь на Vista или лучше, вы можете использовать поддержку реестров транзакций, добавленную в Vista.

К сожалению, нет прямой управляемой поддержки, поэтому вам нужно создать обертку. http://community.bartdesmet.net/blogs/bart/archive/2006/12/14/Windows-Vista-2D00-Introduction-TxR-in-C_2300 _-_ 2800_Part-1_2900_.aspx показывает, как P/вызывать эти методы.

Ответ 3

Windows Server 2008 также поддерживает транзакционный доступ к реестру. Здесь обзор в MSDN. И здесь сообщение в блоге, сообщающее об этом с некоторыми вопросами и ответами.

Ответ 4

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

http://blogs.msdn.com/oldnewthing/archive/2009/03/26/9508968.aspx

Ответ 5

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