Когда использовать блокировку по сравнению с MemoryBarrier в.NET
В.NET lock ключевое слово является синтаксическим сахаром вокруг Monitor.Enter и Monitor.Exit, таким образом, Вы могли сказать что этот код
lock(locker)
{
// Do something
}
совпадает с
Monitor.Enter(locker);
try
{
// Do Something
}
finally
{
Monitor.Exit(locker);
}
Однако платформа.NET также включает MemoryBarrier класс, который работает похожим способом
Thread.MemoryBarrier();
//Do something
Thread.MemoryBarrier();
Я смущен как тогда, когда я хотел бы использовать Thread.MemoryBarrier по lock/Monitor версия? Я сделан еще более смущенным Учебным руководством по Поточной обработке, которое указывает, что они функционируют то же.
Насколько я вижу, что для видимого различия не нужен объект блокировки, который я предполагаю то использование Monitor Вы могли сделать что-то через потоки где MemoryBarrier находится на единственном потоке.
Мой пищеварительный тракт говорит мне, что другое основное отличие MemoryBarrier для переменных только а не для методов.
Наконец это не связано с существующим вопросом, Когда использовать 'энергозависимый' или ‘Поток. MemoryBarrier ()’ в ориентированном на многопотоковое исполнение коде блокировки? (C#), поскольку это фокусируется на volatile ключевое слово, из которого я понимаю его использование.
1 ответ
] На мой взгляд, вы почти [] никогда не должны [] использовать []Thread.MemoryBarrier[]. Это используется для кода []lock-free[] - чтобы изменения, сделанные на одном потоке, были видны на другом без затрат на блокировку. В отличие от [] lock[], он делает [] не[] контроль синхронизации потоков. Я не понимаю, где в учебнике Джо написано, что []MemoryBarrier[] "работает так же", как []lock[]. Не могли бы Вы объяснить, откуда именно у Вас такое впечатление?[
]На мой взгляд, низкоуровневый lock-free код слишком сложен практически для всех, кроме разработчиков, чья основная специализация - параллелизм. Если я захочу написать какой-нибудь lock-free код, я буду использовать более высокоуровневые блоки []build[] от этих разработчиков (например, Parallel Extensions в .NET 4.0), а не пытаться катить свой собственный.[
] []В качестве примера, недавно я открыл глаза на точное значение []volatile[], которое []не является [] "всегда читать из оперативной памяти, всегда писать прямо в оперативную память". (В моем собственном нитевидном учебнике это объяснение до сих пор есть - кое-что, что мне нужно исправить в какой-то момент). [] Это гораздо более тонкое объяснение []. Это значит, что [] некоторые [] из моих предыдущих использований [] volatile[] вполне могут быть некорректны.[