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

S>>Нет, это ненадёжная задержка. Впендюрив сюда volatile, программист запрещает "устраняющие" оптимизации компилятору.
S>>Но, во-первых, это никак не влияет на выбор размещения переменной, поэтому величина задержки получается произвольной даже в пределах одной аппаратуры — то ли будет выполнен сброс в память, то ли обойдёмся регистром. Какова будет разница в величине задержки?
S>>Во-вторых, даже в пределах одной аппаратуры у нас может плавать тактовая частота, и скорость исполнения этого цикла будет меняться в разы.
S>>Во-третьих, нет никакой гарантии, что во время цикла не будет выполнено вытеснение. Тогда можно запросто получить задержку на порядки больше, чем ожидалось.
_>Всё, что ты тут написал может быть справедливо например для написания ОС, но скажем для написания драйвера мотора на конкретном МК, это уже не актуально. )))
Для конкретного исходного кода и всех его зависимостей, конкретной версии компилятора, для конкретных флагов компилятора — да, не актуально. Т.е. процесс разработки будет выглядеть как: написали код, скомпилировали, дизассемблировали, посмотрели, что сгенерировались нужные инструкции в каждом таком месте и только после этого можно отдавать в прод.
Правда смысл этого мероприятия от меня ускользает. Не проще ли тогда тупо вставить asm?

_>Казалось бы при применение CAS никакие volatile не нужны, достаточно только наличие у железа подобной инструкции. Но есть нюансы! ))) Инструкция CAS, как и все атомарные инструкции типа "прочитать-изменить-записать", весьма медленная. Поэтому частенько делают более интеллектуальную схему реализации спинлока: вставляют дополнительный блокирующий цикл ожидания, на обычном быстром чтение памяти (в точности как мой первый пример), а уже после его "прохода" реализуют захват на медленной атомарной функции. Ну и соответственно для возможности написания такой оптимизации, тебе очевидно потребуется volatile.
Можно увидеть пример где так сделано?

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

S>>Нет, это ненадёжная задержка. Впендюрив сюда volatile, программист запрещает "устраняющие" оптимизации компилятору.
S>>Но, во-первых, это никак не влияет на выбор размещения переменной, поэтому величина задержки получается произвольной даже в пределах одной аппаратуры — то ли будет выполнен сброс в память, то ли обойдёмся регистром. Какова будет разница в величине задержки?
S>>Во-вторых, даже в пределах одной аппаратуры у нас может плавать тактовая частота, и скорость исполнения этого цикла будет меняться в разы.
S>>Во-третьих, нет никакой гарантии, что во время цикла не будет выполнено вытеснение. Тогда можно запросто получить задержку на порядки больше, чем ожидалось.
_>Всё, что ты тут написал может быть справедливо например для написания ОС, но скажем для написания драйвера мотора на конкретном МК, это уже не актуально. )))
Для конкретного исходного кода и всех его зависимостей, конкретной версии компилятора, для конкретных флагов компилятора — да, не актуально. Т.е. процесс разработки будет выглядеть как: написали/изменили код, скомпилировали, дизассемблировали, посмотрели, что сгенерировались нужные инструкции в каждом таком месте и только после этого можно отдавать в прод.
Правда смысл этого мероприятия от меня ускользает. Не проще ли тогда тупо вставить asm?

_>Казалось бы при применение CAS никакие volatile не нужны, достаточно только наличие у железа подобной инструкции. Но есть нюансы! ))) Инструкция CAS, как и все атомарные инструкции типа "прочитать-изменить-записать", весьма медленная. Поэтому частенько делают более интеллектуальную схему реализации спинлока: вставляют дополнительный блокирующий цикл ожидания, на обычном быстром чтение памяти (в точности как мой первый пример), а уже после его "прохода" реализуют захват на медленной атомарной функции. Ну и соответственно для возможности написания такой оптимизации, тебе очевидно потребуется volatile.
Можно увидеть пример где так сделано?