Tom wrote:
> ME>Этот код — некорректный многопоточный код, так как он не применяет синхронизацию для доступа к переменной. > > А ты думаешь компилятор перестанет оптимизировать, если появиться синхронизация?
Здравствуйте, What, Вы писали:
E>>А все из-за того, что изначально мы защитились синхронизацией. И не надеялись на особенности конкретной платформы и конткретного компилятора. W>Для того, чтобы не зависеть от платформы, нужно разделять платформенно-зависимый и платформенно-независимый код. А вот платформенно-зависимые примитивы, например, средства синхронизации могут быть реализованы отдельно под некоторые платформы максимально эффективным способом. И если под x86 работа с 32-битными числами атомарна, то в платформенно-зависимых частях кода нужно это использовать.
Так ваша часть была платформо-зависимой! Ok. Тогда volatile была частью этой зависимости.
Если бы код был POSIX-зависимым, или boost-зависимым, или ACE-зависимым, или commoncpp-зависимым, или glib-зависимым, или Win32-EnterCriticalSection/LeaveCriticalSection-зависимым, то volatile не была бы частью этой зависимости.
Я это к тому, что вы выбрали мультипоточную модель под конкретную платформу. Причем модель, которую не все считают корректной. И необходимым условием работоспособности этой модели явилось применение volatile. Но вашем конкретном случае эта модель себя оправдывает.
Спасибо за ваш пример.
W>>>С другой стороны, а если бы рабочих потоков было, скажем, 4 вместо 1. И все читали бы одну и ту же переменную. Тогда использование синхронизации могло бы привести к ненужным потерям производительности. E>>За безопасность в многопоточности нужно платить. Некоторые из-за безопасности на более медленные языки программирования переходят Из-за того, что лишний раз delete вызвать лень W>Да, но зачем платить, когда это не нужно? Например, критические секции, если не надо останавливать поток, обходятся без перехода в режим ядра. Другой пример — паттерн double-checked locking, при реализации которого, кстати, может понадобиться volatile.
Это вы думаете, что платить не нужно. Я считаю, что нужно. Но плату желательно минимизировать. За счет критических секций, хотя бы.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
ME>Ok, ты работаешь над проектом. Менеджер спрашивает тебя, готов ли ты поставить свою зарплату, что твой многопоточный кусок кода, в котором ты не используешь ф-ций синхронизации, а полагаешься на "fuzzy" семантику volatile, заработает на не Intel SMP системе? Что ты ему ответишь?
Ок, вот так согласен
Еще раз — без привязки к конкретной платформе volatile абсолютно бесполезен для multithreading.
Здравствуйте, eao197, Вы писали:
W>>С другой стороны, а если бы рабочих потоков было, скажем, 4 вместо 1. И все читали бы одну и ту же переменную. Тогда использование синхронизации могло бы привести к ненужным потерям производительности. E>За безопасность в многопоточности нужно платить.
Зачем нужна синхронизация с помощью обьектов ядра, когда один поток пишет атомарное значение и несколько других читает это значение?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>Зачем нужна синхронизация с помощью обьектов ядра, когда один поток пишет атомарное значение и несколько других читает это значение?
А в стандарте C++ где нибудь сказано, что вот здесь:
for (unsigned int i = MaxIter; (i != 0) && go; --i)
операция чтения переменной go будет атомарной? По-моему, язык C++ этого никак не гарантирует. Даже с помощью volatile.
А синхронизация нужна хотя бы потому, что чтение общих данных без синхронизации это -- "For every complex problem, there is a solution that is simple, neat, and wrong." (С) AndrewJD
А если серьезно, то лично я считаю, что лучше переплатить за безопасность синхронизацией, чем потом разгребать проблемы.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: E>А в стандарте C++ где нибудь сказано, что вот здесь: E>
E>for (unsigned int i = MaxIter; (i != 0) && go; --i)
E>
E>операция чтения переменной go будет атомарной? По-моему, язык C++ этого никак не гарантирует. Даже с помощью volatile.
Атомарность это понятие относится к платформе, а не к языку. volatile — гарантирует, что оптимизатор не будет позволять себе слишком многого.
E>А синхронизация нужна хотя бы потому, что чтение общих данных без синхронизации это
Для чего нужна синхронизация если тебе важно знать поменялось значение или нет? Тебе не важно САМО значение, тебе важен факт его изменения. Какая тут нужна синхронизация
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, eao197, Вы писали: E>>А в стандарте C++ где нибудь сказано, что вот здесь: E>>
E>>for (unsigned int i = MaxIter; (i != 0) && go; --i)
E>>
E>>операция чтения переменной go будет атомарной? По-моему, язык C++ этого никак не гарантирует. Даже с помощью volatile.
AJD>Атомарность это понятие относится к платформе, а не к языку. volatile — гарантирует, что оптимизатор не будет позволять себе слишком многого.
Про то, что может гарантировать volatile в этой ветви, чуть повыше, уже все подробно объяснили. Я не хочу на этом останавливаться.
Поскольку язык не гарантирует, что чтение переменной go будет атомарным, то мне нужно обеспечить безопасность этого чтения путем синхронизации. Которая относится к платформе, но здесь не используется.
E>>А синхронизация нужна хотя бы потому, что чтение общих данных без синхронизации это
AJD>Для чего нужна синхронизация если тебе важно знать поменялось значение или нет? Тебе не важно САМО значение, тебе важен факт его изменения. Какая тут нужна синхронизация
Ну в данном конткретном случае само значение переменной и указывает на факт его изменения
А по этому конкретному примеру я уже высказал все, что хотел.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Так ваша часть была платформо-зависимой! Ok. Тогда volatile была частью этой зависимости. E>Если бы код был POSIX-зависимым, или boost-зависимым, или ACE-зависимым, или commoncpp-зависимым, или glib-зависимым, или Win32-EnterCriticalSection/LeaveCriticalSection-зависимым, то volatile не была бы частью этой зависимости.
Как сказать... ACE и boost используют volatile в своей реализации.
E>Я это к тому, что вы выбрали мультипоточную модель под конкретную платформу. Причем модель, которую не все считают корректной. И необходимым условием работоспособности этой модели явилось применение volatile. Но вашем конкретном случае эта модель себя оправдывает.
E>Спасибо за ваш пример.
Пожалуйста
Здравствуйте, eao197, Вы писали:
AJD>>Атомарность это понятие относится к платформе, а не к языку. volatile — гарантирует, что оптимизатор не будет позволять себе слишком многого.
E>Про то, что может гарантировать volatile в этой ветви, чуть повыше, уже все подробно объяснили. Я не хочу на этом останавливаться.
Так же выше был пример где использовались критические секции для синхронизации. Но оптимизатор на это забил
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Tom, Вы писали:
Tom>А ты думаешь компилятор перестанет оптимизировать, если появиться синхронизация?
Перестанет. Ибо синхронизация немыслима без вызова внешних функций, в отношении которых компилятор бессилен установить, изменяют ли они значение данной переменной.
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
Здравствуйте, emusic, Вы писали:
E>В этих дискуссиях никто америки не открыл, и большинство компетентных мнений сходится, конечно же, к тому, что ни volatile, ни memory barriers сами по себе проблемы не решают, и в общем случае решают ее лишь в совокупности.
Хм... Если есть барьер, то зачем volatile?
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
Здравствуйте, achp, Вы писали:
A>Хм... Если есть барьер, то зачем volatile?
Бааалин. Глухой телефон Кто обещал, что барьер можно специфицировать на конкретный объект? Если на каждый объект сделать функцию, которая обеспечивает сливание его в память на одном процессоре и всасывание в другом — разумеется, компилятор после выполнения этой функции перечитает любую часть объекта из памяти, ибо в функцию будет передаваться неконстантная ссылка
А если барьер неспецифичный, вроде KeMemoryBarrier в виндовом ядре? Как объяснить компилятору, что после вызова некоторой функции без аргументов последнее известное значение объекта уже нельзя считать валидным? Разумеется, если не применять глубокой оптимизации — компилятор будет осторожничать и перечитывать после каждого вызова неизвестной ему функции. Указание volatile для разделяемых объектов позволит ему максимально оптимизировать остальные объекты. Если охота еще и оптимизации разделяемых объектов — значит, нужны специфичные барьерные примитивы на каждый разделяемый объект.
Здравствуйте, achp, Вы писали:
Tom>>А ты думаешь компилятор перестанет оптимизировать, если появиться синхронизация?
A>Перестанет. Ибо синхронизация немыслима без вызова внешних функций, в отношении которых компилятор бессилен установить, изменяют ли они значение данной переменной.
Это верно только для нелокальных переменных. Я уже приводил код с указателями. В каждом потоке в каждый момент времени существует только один указатель на объект, по которому может производиться доступ. Следовательно, допустимо применить оптимизацию работы с указателями, задав компилятору режим No Aliasing.
Кроме того, если в модуле присутствуют только статические переменные и функции, и указатели на эти статические функции не передаются во внешние функции — компилятор имеет полное право считать, что статические переменные извне изменены быть не могут — за исключением тех, указатели на которые передаются во внешние функции. Пока я не встречал компилятора, который стал бы производить столь глубокий анализ, однако можешь ли ты обосновать некорректность подобного поведения компилятора?
Здравствуйте, What, Вы писали:
W>Здравствуйте, MaximE, Вы писали:
W>You do NOT need volatile for threaded programming. You do need it when you share W>data between "main code" and signal handlers, or when sharing hardware registers W>with a device.
Мне очень интересно, на что опираются подобные утверждения, кроме голой интуиции Как этот народ технически различает "threaded" и "hardware registers"? Допустим, у меня есть однопроцессорная машина и "device" — плата расширения, втыкаемая в PCI, на которой стоит такой же процессор, что и в системной плате. Я посредством каких-нибудь спецкоманд запускаю выполнение этим "внешним" процессором какой-нибудь части собственного кода. Память — общая, доступ возможен как с моей, так и с той стороны. Это "threaded" или "device"?
Здравствуйте, MaximE, Вы писали:
ME>Ok, ты работаешь над проектом. Менеджер спрашивает тебя, готов ли ты поставить свою зарплату, что твой многопоточный кусок кода, в котором ты не используешь ф-ций синхронизации, а полагаешься на "fuzzy" семантику volatile, заработает на не Intel SMP системе?
А ты свою зарплату за то, что код, использующий функции синхронизации, но не использующий volatile, заработает везде, поставишь? Только хорошо подумай перед тем, как согласиться
Макс, ты тут ругал человека, что он не читает тред — а ты сам его разве читаешь? Тебе в который раз повторяют, что для гарантированной работы кода в общем случае обязательны и функции синхронизации, и volatile. Но тебе, похоже, комфортнее делать вид, будто все, как один, сторонники volatile предлагают использовать его вместо функций синхронизации Тебе не надоело упираться рогом в стену?
А в частных случаях, разумеется, можно обойтись как одним volatile, так и одной синхронизацией. Очевидный, в общем-то, вывод.
Здравствуйте, emusic, Вы писали:
E>Это верно только для нелокальных переменных. Я уже приводил код с указателями. В каждом потоке в каждый момент времени существует только один указатель на объект, по которому может производиться доступ. Следовательно, допустимо применить оптимизацию работы с указателями, задав компилятору режим No Aliasing.
Ну правильно, это же прямой обман компилятора. И вообще это чрезмерно агрессивная оптимизация, в общем случае недопустимая.
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
