Изопропилgandjustasvolatile не сериализует доступ, в MSDN не точное описание. volatile не является средством синхронизации для многопроцессорных компьютеров.
да, это так.Нет, это не так. volatile и сериализует доступ к конкретной переменной (напр. к long на 32-битной платформе), и является примитивом синхронизации благодаря окружающим его барьерам памяти.

hVosttТы вообще не понимаешь что такое volatile . Может хоть один букварь откроешь наконец, а? Выглядишь глупо, честно.Хм, то есть volatile не гарантирует атомарность записи, и вокруг него нет барьеров?

hVosttКогда разберёшься, у тебя все вопросы сразу отпадут по поводу того, почему принципиально и технически в среде .NET (на сегодняшний день) нельзя объявить volatile long и double . Ты отчётливо поймёшь почему. И поймёшь, что на месте разработчиков ты бы сделал также.А вы не можете мне ответить на этот вопрос? Почему нельзя?
Вот я работаю в 64-битной среде, у меня есть ссылка, она занимает 8 байт. Ее можно объявить volatile.
Вот я работаю в 64-битной среде, и у меня есть long. Ее нельзя объявить volatile.
Но при этом у меня есть Thread.VolatileRead(ref long), где long все таки можно читать/писать как volatile, вне зависимости от того, сижу я в 64-битной или 32-битной среде.
Что я не понимаю?

Где-то в степиcdtyjv,
летучесть это фишка записи и чтения данных процессора в контексте его кеша( процессора), если два разных потока
крутятся на разных ядрах , работат с переменными оптимизирована через кеш каждого процессора, то есть фактическое изменение
переменной задерживается в кеше, а если оно задерживается то второе ядро не может получить реальное значение.
volatile дает команду процессору изменить значение переменной минуя ее копию в кеше ( сквозное изменение) и автоматом объявляет кеш не действительным - отсюда и вся гадость со скоростью доступа к кешу ядра ( приходится опять заныривать в оперативку).Ну вы совершенно не правы. volatile переменные сидят в кэше так же, как и все остальные. Они отличаются от обычных переменныъ только двумя вещами:
1) Компилятору запрещено оптимизирвоать доступ к ним. То есть, если у меня в коде идет два чтения volatile, то register allocator компилятора не может прочитать ее один раз, сохранить в регистр, а второй раз прочитать копию из него. Он обязан дважда обратиться в подсистему памяти (а подсистема памяти - это кэщ + оперативка, процессор их не отличает друг от друга).
2) Вокруг доступов к волатильным переменным выставляют барьеры, которые гарантируют синхронизацию кэшей разных ядер. Не то, что "переменная будет прочитана из памяти, а не из кэша" - это распространенное заблуждение. А то, что на записи волатиля ядро сбросит store buffer своего кэша в кэши других ядер, я чтение волатиля сначала обработает invalidate queue своего ядра, и лишь потом ее прочитает (либо из памяти, либо из кэша другого ядра через механизм snooping'а).

ИзопропилcdtyjvНо при этом у меня есть Thread.VolatileRead(ref long
вскрытие показывает, что на 32 бит он не атомарен. селявиДа, действительно. Зато атомарен Interlocked. Еще бОльшая кривота .Net'а.

hVosttcdtyjv,

На всякий случай, одно из классических применений volatile , это когда поток 1 изменяет переменную, а поток 2 читает, при этом не обеспечивается 100% гарантия актуального значения переменной в один и тот же момент времени. При этом, если не использовать volatile , поток 2 может так и не увидеть изменений, или получать совсем не актуальное значение.

Для синхронизации потоков, volatile категорически не используется, как и «волатильные» чтение/запись.Угу, не используется. Например, вот здесь это не используется http://referencesource.microsoft.com/#mscorlib/system/threading/SpinLock.cs

Все современные синхронайзеры, будь то ReentrantReadWriteLock в Java или какой-нибудь ReaderWriteLockSlim в Net ( http://reflector.webtropy.com/default.aspx/4@0/4@0/untmp/DEVDIV_TFS/Dev10/Releases/RTMRel/ndp/fx/src/Core/System/Threading/ReaderWriterLockSlim/ReaderWriterLockSlim@cs/1305376/ReaderWriterLockSlim@cs)]http://reflector.webtropy.com/default.aspx/4@0/4@0/untmp/DEVDIV_TFS/Dev10/Releases/RTMRel/ndp/fx/src/Core/System/Threading/ReaderWriterLockSlim/ReaderWriterLockSlim@cs/1305376/ReaderWriterLockSlim@cs) используют volatile/interlocked для попытки быстрого захвата ресурса, читай - быстрого занятия критической секции. А если это не получается, то они идут в ОС, и просят ее о помощи.

По слову futex погуглите - та же самая концепция.

hVosttВот где твой косяк в отношении понимания модификатора volatile и «волатильным» чтением/записью.

И ещё, кажется, что ты путаешь volatile с Interlocked , последний гарантирует атомарность операции, в то время как volatile — отнюдь не гарантирует.Да, так и есть. Просто криворукие разработчики .Net решили не давать гарантии атомарности long/double, из-за чего и возник весь сыр-бор с невозможностью объявить их volatile, а оттуда же выросли проблемы с дженериками, которые так же нельзя объявить волатилями. Одно тупое решение какого-то неквалифицированного индуса, и API .Net превратился в гомно.

Где-то в степину сидят в кеше, вам то от этого чем легче, при записи происходит изменение переменной в кеше с последующим сбросом в основную память и объявлением последнего не действительнымЭто неправда. Тактика процессора в одношении "сброса" данных из кэшей в память относительно волатильных и неволатильных переменных одинакова. Это следуте из того простого факта, что если вы посмотрите на соответствующий ассемблерный код, то увидите, что и обычная запись, и волатиьлная - это просто инструкция mov. Нет способа сказать процессору, что это волатиьлная переменная, а эта нет. Он их не отличает. Но вокруг волатильных переменных компилятор добавляет барьеры (например, cmpxchg), которые гарантируют частичную синхронизацию состяний кешей между собой, а не между кэшем и памятью.