Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет yigal_s ([info]yigal_s)
@ 2010-10-28 01:12:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
программизм: volatile or non-volatile
Небезынтересно наблюдать за эволюцией смысла ключегого слова volatile в разных языках и даже разных компиляторах.
Желающие работать с памятью атомарно, вернее, без локов, частенько используют это слово на С++ почем зря. С другой стороны, и убирать его порой как-то страшно бывает. Некоторым. ;-)
Во всяком случае, без качественной подготовки инфраструктуры лично я бы его не убирал. Хотя и использовать его всерьез - ошибочно.

Вот и Майкрософт, к примеру, имеет

LONG InterlockedIncrement(LONG volatile *Addend);

функцию с volatile параметром и точно такую же intrinsic

long _InterlockedIncrement( long * lpAddend );

но уже без volatile.

"Мужыки, что сказать-то хотели???"

(Добавить комментарий)

панимать же нада блин
[info]mediant@lj
2010-10-28 04:30 (ссылка)
volatile это ж не для тебя, а для компилятора. про intrinsic он и так все знает, так что разберется.

(Ответить) (Ветвь дискуссии)

Re: панимать же нада блин
[info]yigal_s@lj
2010-10-28 05:27 (ссылка)
> панимать же нада

Очень верное замечание, кстати.

> volatile это ж не для тебя, а для компилятора

Надо ж. И что такого особого должен сделать компилятор, увидев передачу указателя на волотайл, чего он может не делать при передаче указателя не на волотайл? :-)

> про intrinsic он и так все знает, так что разберется

Ну по такой логике можно вообще декларацию этой функции привести как

long _InterlockedIncrement();

"он и так все знает, так что разберется."


(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: панимать же нада блин
[info]mediant@lj
2010-10-28 08:57 (ссылка)
И что такого особого должен сделать компилятор, увидев передачу указателя на волотайл, чего он может не делать при передаче указателя не на волотайл? :-)

Не выдаст сообщение об ошибке, которое появляется при передаче адреса volatile переменной :-P
Обрати внимание, что в intrinsic что не передавай - пох.

Ну по такой логике можно вообще декларацию этой функции привести как
long _InterlockedIncrement();
"он и так все знает, так что разберется."

Запросто. Одно осталось - надрессировать его подставлять нужные аргументы. Но из контекста это должно быть понятно :)

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: панимать же нада блин
[info]yigal_s@lj
2010-10-28 09:29 (ссылка)
> Не выдаст сообщение об ошибке, которое появляется при передаче адреса volatile переменной :-P

Вот вот. Осталось только понять зачем кому-то может понадобиться использовать volatile переменную в таком контексте. :-)))

> Обрати внимание, что в intrinsic что не передавай - пох

Да? Интересно. А ежели указатель на const long? :-) Тоже съест?

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: панимать же нада блин
[info]mediant@lj
2010-10-28 13:37 (ссылка)
Вот вот. Осталось только понять зачем кому-то может понадобиться использовать volatile переменную в таком контексте. :-)))
ну есть типа контексты, для которых ваще-то volatile изначально вводили. shared memory, к примеру.

Да? Интересно. А ежели указатель на const long? :-) Тоже съест?
всех съест. это такая черная дыра ;)

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: панимать же нада блин
[info]yigal_s@lj
2010-10-28 14:15 (ссылка)
ну, положим, с произвольной shared memory работать через волатайл - это те же грабли. Ибо несколько процессов бегущих поверх шаред мемори ничем семантически не отличаются от мультитреда.

Т.ч. для чего вводили волатайл - это небезынтересный философский и практический вопрос. Но уж точно, как выясняется, не для поддержки мультитреда. Привет Микрософту с его волатальными мемори барриерс. :=)

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: панимать же нада блин
[info]mediant@lj
2010-10-28 14:28 (ссылка)
ну, положим, с произвольной shared memory работать через волатайл - это те же грабли. Ибо несколько процессов бегущих поверх шаред мемори ничем семантически не отличаются от мультитреда.
дык отличаются ж, факт. поэтому то и грабли, когда есть желание только к некоторым данных через volatile доступаться.

Т.ч. для чего вводили волатайл - это небезынтересный философский и практический вопрос. Но уж точно, как выясняется, не для поддержки мультитреда.
не очень-то оно вяжется с Я как бы по этому поводу очень давно осведомлен

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: панимать же нада блин
[info]yigal_s@lj
2010-10-28 14:36 (ссылка)
ФАКТ, что НЕ отличаются. Треды - это процессы, бегущие поверх общей памяти. Точка.


* не очень-то оно вяжется с Я как бы по этому поводу очень давно осведомлен

не придирайся, действительно давно. Я Бутенхофа как раз и читал, правда, его мнение хоть и верное, но контекст, в котором он его высказал, несколько устарел (он вообще не имел в виду атомарные операции, а лишь работу под локами).

(Ответить) (Уровень выше)

Re: панимать же нада блин
[info]yigal_s@lj
2010-10-28 14:38 (ссылка)
не то что не имел в виду атомарных операций, а был противником их использования. Опять же, в том контексте это было адекватно.

(Ответить) (Уровень выше)

Re: панимать же нада блин
[info]yigal_s@lj
2010-10-28 14:53 (ссылка)
заметь, ты даже конструктор С++ объекта не сможешь запустить поверх волатальной памяти :-)

(Ответить) (Уровень выше)

Re: панимать же нада блин
[info]yigal_s@lj
2010-10-28 14:33 (ссылка)
вот прикинь, объявил ты shared memory as volatile, then you take some associated exclusive lock and are trying just to memcpy smth. into it, like

memcpy(shared_mem, src, n)

and... you fail 'cause shared_mem is a pointer to volatile and memcpy can not accept it.

Can you furnish an adequate solution for this?

(Ответить) (Уровень выше)

Re: панимать же нада блин
[info]mediant@lj
2010-10-28 09:00 (ссылка)
отдельно - _InterlockedIncrement можно определять как volatile (см. intrin.h), так и нет. компилятору все пох.

(Ответить) (Уровень выше)


[info]mediant@lj
2010-10-28 09:10 (ссылка)
Кстати, как тебе такое по теме:
http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/

Что бы мы делали, панимаишь, не будь родного Microsoft Specific (http://msdn.microsoft.com/en-us/library/12a04hfd.aspx)

(Ответить) (Ветвь дискуссии)


[info]yigal_s@lj
2010-10-28 09:35 (ссылка)
Я как бы по этому поводу очень давно осведомлен.

> Что бы мы делали, панимаишь, не будь родного Microsoft Specific

И это опять же крайне небезынтересный вопрос. Решение микрософта не беспроблемно - они в который раз скрестили ужа с ежом, навязав volatile дополнительную семантику.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mediant@lj
2010-10-28 13:39 (ссылка)
там в комментариях тож кому-то нехватало __declspec(mfence) :)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]yigal_s@lj
2010-10-28 14:24 (ссылка)
Ну там много чего разного может не хватить.

Вообще говоря, Сx0 стандарт собирается эту тему закрыть, наконец.
Правда, там тоже используется волатайл, но, кажется, адекватно.
Хотя, это опять же путает неслабо.

(Ответить) (Уровень выше)


[info]alnik@lj
2010-11-04 17:31 (ссылка)
volatile используется для указания компилятору, что объект может измениться непредсказуемым образом, т.е., например, чтобы оптимизатор не выкидывал из двух подряд идущих чтений по одному адресу второе.

А за Майкрософт я отвечать не буду ;)

(Ответить) (Ветвь дискуссии)


[info]alnik@lj
2010-11-04 18:21 (ссылка)
Прочитал у Вас про memory oredering - понял, что Вы про volitile и сами знаете. :)

(Ответить) (Уровень выше)


[info]yigal_s@lj
2010-11-04 22:53 (ссылка)
> volatile используется для указания компилятору, что объект может измениться непредсказуемым образом, т.е., например, чтобы оптимизатор не выкидывал из двух подряд идущих чтений по одному адресу второе.

Ну, например, да. Хотя есть и другие свойства - например, чтобы оптимизатор не выкидывал из двух подряд записей - первую. И еще некоторые иные свойтства есть.

Соответственно, может создаться _впечатление_, что атомарные операции должны работать с volatile данными (как в интерфейсе Микрософта) - они ведь действительно могут меняться непредсказуемым образом.

(Ответить) (Уровень выше)