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

S>Поправьте где неправ:
S>1. volatile в С# — какая-то шляпа

Нет, оно работает так как должно. Штука очень полезная, особенно если ты шаришь память между между процессами (например с помощью MMF). Например, у тебя выделена память с помощью VirtualAlloc(), в которой ты сделал окно. Ты на неё смотришь через стуктуру (приводишь к указателю на структуру). Все поля этой структуры должны быть volatile — компилятор никогда не сможет угадать, кто и когда поменяет эту память. Фактически это указание компилятору, что к памяти имеет доступ кто-то ещё.

S>2. lock — вроде как ведет к Memory Barier, правда неявно

Да, это так.

S>3. у нас есть Interlocked, которого хватает в 99%
Нет: кому-то хватает, а кому-то нет. Interlocked в конечном счёте выставляет префикс lock на операции обращения к памяти. Это приодит к сигналу Lock на шине процессора при исполнение — производительность на таких штуках серьёзно деградирует.
В принципе любые примитивы синхронизации приводят к деградации производительности. Чем более они высокоуровневые — тем сильнее, хотя с походами в ядро им конечно не сравниться.

Насчёт Interlocked: в циклах ожидания нужно использовать процессорную инструкцию pause, но из C# этого сделать невозможно. Вот пример:

            while (1 == Interlocked.CompareExchange(ref m_dwBusy, 1, 0))
            {
                //здесь должна быть pause
            }

Т.е. я не знаю — по-моему это ещё не ушло в релиз.

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

S>Поправьте где неправ:
S>1. volatile в С# — какая-то шляпа

Нет, оно работает так как должно. Штука очень полезная, особенно если ты шаришь память между между процессами (например с помощью MMF). Например, у тебя выделена память с помощью VirtualAlloc(), в которой ты сделал окно. Ты на неё смотришь через стуктуру (приводишь к указателю на структуру). Все поля этой структуры должны быть volatile — компилятор никогда не сможет угадать, кто и когда поменяет эту память. Фактически это указание компилятору, что к памяти имеет доступ кто-то ещё.

S>2. lock — вроде как ведет к Memory Barier, правда неявно

Да, это так.

S>3. у нас есть Interlocked, которого хватает в 99%
Нет: кому-то хватает, а кому-то нет. Interlocked в конечном счёте выставляет префикс lock на операции обращения к памяти. Это приодит к сигналу Lock на шине процессора при исполнение — производительность на таких штуках серьёзно деградирует.
В принципе любые примитивы синхронизации приводят к деградации производительности. Чем более они высокоуровневые — тем сильнее, хотя с походами в ядро им конечно не сравниться.

Насчёт Interlocked: в циклах ожидания нужно использовать процессорную инструкцию pause, но из C# этого сделать невозможно. Вот пример:

            while (1 == Interlocked.CompareExchange(ref m_dwBusy, 1, 0))
            {
                //здесь должна быть pause
            }

Т.е. я не знаю — по-моему это ещё не ушло в релиз.