Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, remark, Вы писали:


R>>В случае передачи от читателя к писателю — проблема, т.к. одним барьером нельзя сделать синхронизацию. Т.е. грубо говоря, при передаче владения от читателя к писателю выполнение читателей и писателя "наложится во времени" с непредсказуемыми результатами.

V>Там было не про передачу управления, а о доступе к атомарной ячейке памяти (в которой указатель, например). Писателю нужно сделать 2 барьера — до и после модификации этой ячейки, читателю — только до. Если в момент чтения читателем в многопроцессорной системе писатель тоже можифицирует ячейку — фиг с ним, в близком времени эта модификация видна будет только после барьера этого писателя.

Почему *только* после барьера писателя? По моим представлениям модификация может быть видна и до барьера, выполненного писателем... если, конечно, мы не говорим о non cache-coherent системах...

Здравствуйте, remark, Вы писали:


R>Почему *только* после барьера писателя? По моим представлениям модификация может быть видна и до барьера, выполненного писателем... если, конечно, мы не говорим о non cache-coherent системах...

Не суть, будет ли она видна до барьера. Барьер, при доступе к атомарной ячейке после записи "ускоряет" обнаружение изменений у читателей.

R>

Здравствуйте, vdimas, Вы писали:

R>>Почему *только* после барьера писателя? По моим представлениям модификация может быть видна и до барьера, выполненного писателем... если, конечно, мы не говорим о non cache-coherent системах...

V>Не суть, будет ли она видна до барьера.

Ну как же не суть! Это как раз основное, что обеспечивает мьютекс. Если нас устраивает ситуация, что читатели читают произвольную помесь из разных версий данных, то нам мьютекс и вообще не нужен.

V>Барьер, при доступе к атомарной ячейке после записи "ускоряет" обнаружение изменений у читателей.

Здравствуйте, nikov, Вы писали:

СЮГ>>1) В языке C# есть такое правило, что если функция объявлена так: void F (ref int x) то фактический параметр x не может быть volatile.

N>Кстати, Вы не знаете, какое обоснование для этого правила?

Насколько я понимаю, запись в volatile-переменную должна вызывать появление некоторого дополнительного кода непосредственно в районе инструкции записи. Ну там memory barrier какой-нибудь взвести и т.п.
Однако в случае ref неизвестно что за переменная с "той" стороны: обычная или volatile. Вот и задано явное ограничение.

Наверняка это можно было обрулить, но я вижу только пути с существенной потерей производительности покамест...

Здравствуйте, С. Ю. Губанов, Вы писали:

R>>Если flag объявлен как volatile, то да, если нет — то нет.

СЮГ>А Вы вообще как, знаете что такое язык C#? И что означает слово volatile в этом языке? Вы его с Си или с Си++ не перепутали случайно? Пожалуй, перепутали.

СЮГ>Напоминаю:

СЮГ>1) В языке C# есть такое правило, что если функция объявлена так: void F (ref int x) то фактический параметр x не может быть volatile.


Читаю блог Joe Duffy:
http://www.bluebytesoftware.com/blog/CommentView,guid,1665653b-b5f3-49b4-8144-cfbc5e8c632b.aspx

Тут он делает именно это — переменную, объявленную как volatile, передаёт в Interlocked.Exchange(). Единственное на это выдаётся варнинг, который в данном случае просто false positive. А так всё работает.
Возможно он использует более позднюю версию языка и компилятора. Но тем не менее теперь это можно делать.