Re[3]: ужас
От: achp  
Дата: 20.01.05 10:34
Оценка:
Здравствуйте, MaximE, Вы писали:

ME>Гарантируется. После вызова "непрозрачной" ф-ции компилятор будет перечитывать значения всех переменных из памяти. В противном случае даже single threaded код работать не будет.


Ну, положим, не совсем всех. Если это локальная переменная, адрес которой нигде "налево" не "утекал", то её вполне можно заховать и в регистре.
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
Re[4]: ужас
От: achp  
Дата: 20.01.05 10:34
Оценка:
Здравствуйте, Seriously Serious, Вы писали:

SS>А если ВСЕ функции станут прозрачными и компилятор будет ВСЁ держать в регистрах?


Во-первых, из "прозрачности" ещё не следует, что можно "всё держать в регистрах". "Прозрачность", то есть доступность для компилятора тела данной функции, может позволить компилятору сделать вывод о том, какие объекты подвергаются модификации при её вызове, а какие — нет. А может и не позволить.

Во-вторых, тогда барьеры (и многопоточность вообще) станут просто невозможны.
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
Re[3]: volatile у переменной класса
От: MaximE Великобритания  
Дата: 20.01.05 10:50
Оценка:
Mr. None wrote:

> ME>volatile не имеет никакого отношения к multithreading, поэтому его применение в этой ситуации не только бесполезно, но может быть и вредно, так как с volatile компилятор не сможет соптимизировтать доступ к этой переменной. Но если один из потоков изменяет переменную, синхронизация при помощи мютексов обязательна.

>
> Так надоело по крупицам вылавливать информацию о volatile и multithreading`ге и некоторых других особенностях плюсов, связанных с этим... Максим, если у вас богатый опыт в этом вопросе, может наконец-то статью напишете, где изложите все свои знания насчёт этих вопросов? Интересно было бы почитать...

К сожалению, опыт у меня не большой и очень узкий, и к разработке компиляторов и моделей памяти я не причастен.

Чему могу научить — так это пользоваться google'ом для поиска информации.

--
Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9
Re[10]: [2]: : volatile: а можно примеры?
От: MaximE Великобритания  
Дата: 20.01.05 10:53
Оценка: +1
eao197 wrote:

> ... Поэтому еще раз проясню свою позицию: я хочу увидеть реальные примеры (из реальных, а не тестовых примеров), когда использовались примитивы синхронизации, но приложение все равно работало не правильно до тех пор, пока не было использовано volatile. При этом меня не интересуют ни обработчики аппаратных прерываний, ни работа с железом через отображаемые в память порты ввода/вывода.

>
> Прошу не приводить примеров, когда компилятору специальными ключами явно указывали, что ни одна функция не имеет побочных эффектов. Применение такого ключа в многопоточной программе, ИМХО, является проявлением излишнего оптимизма программиста. Кроме того, такой пример я уже видел. Может есть что-то еще?

Полностью согласен и тоже хочу увидеть пример.

--
Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9
Re[7]: [2]: : volatile: а можно примеры?
От: achp  
Дата: 20.01.05 11:01
Оценка:
Здравствуйте, Шахтер, Вы писали:

Ш>
Ш>CRITICAL_SECTION cs;
Ш>volatile int var1,var2,var3;

Ш>{
Ш> ...
 
Ш> EnterCriticalSection(&cs);

Ш> locked(var1,var2,var3)
Ш>  {
Ш>   // var1,var2,var3 здесь перестают рассматриваться как volatile
Ш>  }

Ш> LeaveCriticalSection(&cs);

Ш> ...
Ш>}
Ш>


Я бы предпочёл код такого вида:

CRITICAL_SECTION cs;
int sealed var1, var2, var3; // sealed - квалификатор, аналогичный const и volatile

int interlocked_get_value(int sealed& v)
{
    return const_cast<int&>(v); // в архитектуре с атомарным доступом к целому
}

int interlocked_increment(int sealed& v);

int f()
{
    ...
    
    int t;
    
    t = var1; // нельзя, доступ запрещён - квалификатор sealed
    t = interlocked_get_value(var1);
    
    var2 = t; // нельзя, доступ запрещён - квалификатор sealed
    interlocked_increment(var2);
 
    EnterCriticalSection(&cs);

    {
        unsealed var1, var2;
        
        // В данной области видимости у объектов var1, var2 квалификатор sealed снимается
        
        var2 = var1;
    }

    LeaveCriticalSection(&cs);

    ...
}


volatile лучше оставить для обработки сигналов и регистров, для чего он и предназначен.
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
Re[4]: ужас
От: MaximE Великобритания  
Дата: 20.01.05 11:17
Оценка:
Tom wrote:

[]

> Что такое "непрозрачные" функции,


Те ф-ции, исходный код которых компилятору недоступен, или компилятор не может сделать выводов об эффектах ф-ции.

> где о них упоминание в стандарте


ISO IEC 9899 C99 Language Standard
5.1.2 Program execution

> и кем карантируется то, что ты сказал?


Об этом позже.

--
Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9
Re[6]: volatile у переменной класса
От: MaximE Великобритания  
Дата: 20.01.05 11:23
Оценка:
Andrew S wrote:

> ME>Конечно, защитников volatile это не убедит, т.к. они скажут, что в ms знали особенности компилятора и нужные ключи компиляции, когда они компилировали ф-ции EnterCriticalSection et al.

>
> А что на нее глядеть? Она пользуется извне только для отладочных целей (соотв, когда никакой оптимизации и нет).

Код ф-ций EnterCriticalSection et al компилировался с этим определением ст-ры.

--
Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9
Re[4]: ужас
От: MaximE Великобритания  
Дата: 20.01.05 11:26
Оценка: :)
achp wrote:

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

>
> ME>Гарантируется. После вызова "непрозрачной" ф-ции компилятор будет перечитывать значения всех переменных из памяти. В противном случае даже single threaded код работать не будет.
>
> Ну, положим, не совсем всех. Если это локальная переменная, адрес которой нигде "налево" не "утекал", то её вполне можно заховать и в регистре.

Он может утечь не явно.

("Непрозрачная") ф-ция может взять адрес возврата, по .pdb файлу определить, что это за вызывающая ф-ция, получить адрес ее фрейма и пробежаться по ее переменным и аргументам — no big deal.

--
Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9
Re[5]: ужас
От: MaximE Великобритания  
Дата: 20.01.05 11:28
Оценка: 12 (1)
achp wrote:

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

>
> SS>А если ВСЕ функции станут прозрачными и компилятор будет ВСЁ держать в регистрах?
>
> Во-первых, из "прозрачности" ещё не следует, что можно "всё держать в регистрах". "Прозрачность", то есть доступность для компилятора тела данной функции, может позволить компилятору сделать вывод о том, какие объекты подвергаются модификации при её вызове, а какие — нет. А может и не позволить.
>
> Во-вторых, тогда барьеры (и многопоточность вообще) станут просто невозможны.

Еще примерчик. Любая "непрозрачная" ф-ция может изменить errno. errno не объявлен volatile.

--
Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9
Re[7]: volatile у переменной класса
От: Andrew S Россия http://alchemy-lab.com
Дата: 20.01.05 11:39
Оценка:
>>
>> А что на нее глядеть? Она пользуется извне только для отладочных целей (соотв, когда никакой оптимизации и нет).

ME>Код ф-ций EnterCriticalSection et al компилировался с этим определением ст-ры.


Это заявление сделано на основании анализа исходников, доступных в сети, или же просто домыслы?
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[5]: Счетчики в CRITICAL_SECTION
От: emusic Франция https://software.muzychenko.net/ru
Дата: 20.01.05 11:42
Оценка:
Здравствуйте, MaximE, Вы писали:

E>>Надо отдать должное реализации этих функций: если секция не захвачена другим потоком — объекты синхронизации не задействуются, все выливается только в вызовы InterlockedXXX.


ME> LONG LockCount;

ME> LONG RecursionCount;

ME>Каунтеры не объявлены как volatile.


А необязательно. Cache cogerency в x86 имеется, для работы с этими счетчиками в NTDLL используются lock-префиксы (в базовой версии DLL там nop'ы, в MP вставляются lock'и). На Alpha/PPC, соответственно, используются более другие способы.

Вообще, какой смысл так упираться, пытаясь доказать ненужность volatile вообще, но почему-то посредством исключительно частных случаев?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Re[2]: Поведение C++ runtime
От: Костя Ещенко Россия  
Дата: 20.01.05 11:45
Оценка: 8 (1)
eao197 wrote:

> Шутки-шутками, но допустим, я захотел, чтобы моя программа использовала мою функцию strlen. Я не описываю ее прототипа, т.к. он определен в <cstring>, просто прилинковываю к программе еще один obj или lib. Но задачей моей strlen, кроме основной работы, может быть, скажем сбор статистики. Или strlen помещает последнюю вычесленную длину в глобальную переменную, чтобы она была доступна без повторного обращения к strlen. Или кэширует адреса строк и их длины для того, чтобы повторно не вычислять длину той же самой строки. Для этого моя strlen модифицирует какие-либо глобальные данные. Которые могут быть определены даже в другой lib-е. Так вот мне интересно, имеет ли право компилятор, встретив где-то в коде strlen посчитать, что он все знает про эту функцию (она же из стандартной библиотеки) и оптимизировать все, что находится вокруг нее? Причем меня волнует компилятор, который, пока, делает основную оптимизацию, а не линкер, который-то явно будет знать, что strlen не стандартная.

>
> Пример с strlen может быть и притянут с потолка. Но почему такого не может быть с malloc/free/realloc? Ведь предоставление своих версий глобальных new и delete является распространенной практикой.

Объявление/определение функции из стандартной библиотеки С, например strlen, в глобальном или ::std неймспейсах с внешней компоновкой приводит к ub. Это значит что можно создать strlen только либо в своем неймспейсе, либо локальную, либо статическую (с внутренней компоновкой).
В 17.4.3 вообще куча страшилок, но new/delete и некоторые другие специально разрешено переопределять.
Posted via RSDN NNTP Server 1.9
На самом деле, люди не читают газеты, они принимают их каждое утро, так же как ванну. ©Маршалл Мак-Льюэн
Re[5]: ужас
От: achp  
Дата: 20.01.05 11:45
Оценка:
Здравствуйте, MaximE, Вы писали:

ME>Он может утечь не явно.


ME>("Непрозрачная") ф-ция может взять адрес возврата, по .pdb файлу определить, что это за вызывающая ф-ция, получить адрес ее фрейма и пробежаться по ее переменным и аргументам — no big deal.


Это уже мошенничество. Если автор такое делает, то это из той же оперы, что и "assume no aliasing".
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
Re[6]: ужас
От: Andrew S Россия http://alchemy-lab.com
Дата: 20.01.05 11:46
Оценка:
ME>Еще примерчик. Любая "непрозрачная" ф-ция может изменить errno. errno не объявлен volatile.

Потому что для каждого потока он свой
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[2]: Поведение C++ runtime
От: emusic Франция https://software.muzychenko.net/ru
Дата: 20.01.05 11:52
Оценка:
Здравствуйте, eao197, Вы писали:

E>имеет ли право компилятор, встретив где-то в коде strlen посчитать, что он все знает про эту функцию (она же из стандартной библиотеки) и оптимизировать все, что находится вокруг нее?


Сам по себе — конечно, нет. Но многие компиляторы имеют intrinsic-версии распространенных коротких функций, и strlen часто в их числе. Тогда вместо вызова генерируется инлайновый код. Чтобы подменить такую функцию, надо сказать компилятору, что такой замены делать не нужно. Для VC++ это #pragma function.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Re[5]: ужас
От: Seriously Serious  
Дата: 20.01.05 11:53
Оценка:
Здравствуйте, achp, Вы писали:

A>Во-первых, из "прозрачности" ещё не следует, что можно "всё держать в регистрах". "Прозрачность", то есть доступность для компилятора тела данной функции, может позволить компилятору сделать вывод о том, какие объекты подвергаются модификации при её вызове, а какие — нет. А может и не позволить.

В каких случаях?

A>Во-вторых, тогда барьеры (и многопоточность вообще) станут просто невозможны.

Вот я и об этом.
Re[6]: Изменение errno
От: emusic Франция https://software.muzychenko.net/ru
Дата: 20.01.05 11:59
Оценка:
Здравствуйте, MaximE, Вы писали:

ME>Любая "непрозрачная" ф-ция может изменить errno. errno не объявлен volatile.


Он внешний следовательно, компилятору принципиально не может быть известно количество желающих его модифицировать, и оптимизации он никак не подлежит.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Re[5]: Неявная модификация
От: emusic Франция https://software.muzychenko.net/ru
Дата: 20.01.05 11:59
Оценка:
Здравствуйте, MaximE, Вы писали:

ME>("Непрозрачная") ф-ция может взять адрес возврата, по .pdb файлу определить, что это за вызывающая ф-ция, получить адрес ее фрейма и пробежаться по ее переменным и аргументам — no big deal.


Тогда можно и проще — скастить функцию в указатель на другой прототип, вызвать — и нехай компилятор разгребает то, что в итоге получится
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Re[7]: ужас
От: MaximE Великобритания  
Дата: 20.01.05 12:15
Оценка:
Andrew S wrote:

> ME>Еще примерчик. Любая "непрозрачная" ф-ция может изменить errno. errno не объявлен volatile.

>
> Потому что для каждого потока он свой

Да, это сакральное занание доступно единицам (в Линукс при многопоточности это вообще макрос вызова ф-ции).

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

--
Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9
Re[7]: Изменение errno
От: MaximE Великобритания  
Дата: 20.01.05 12:16
Оценка:
emusic wrote:

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

>
> ME>Любая "непрозрачная" ф-ция может изменить errno. errno не объявлен volatile.
>
> Он внешний следовательно, компилятору принципиально не может быть известно количество желающих его модифицировать, и оптимизации он никак не подлежит.




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

--
Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.