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

CS>На моей задаче aliasing оптимизация дает 16% прирост производительности. Поэтому без этой оптимизации я даже и не компилирую.
CS>http://terrainformatica.com/htmlayout

Это веский аргумент. Но применяя такую оптимизацию нужно быть готовым к тому, что даже однопоточное приложение без volatile работать не будет. Например:

tm * parsed = localtime( time( 0 ) );
int * sec = &parsed->tm_sec;
while( <something> )
    {
        <do something>
        localtime( time( 0 ) );
        if( *sec ) ...
    }

Что удержит компилятор от того, чтобы не закешировать в регистре значение по указателю sec? /чтобы не было возражений по поводу корректности сохранения в sec указателя на возвращаемое localtime значение хочу сразу сказать, что вместо localtime можно было бы использовать любую другую функцию для которой это можно считать корректным/

В качестве оффтопика хочу заметить, что этот аргумент становится действительно веским при условии, что алгоритмически увеличить быстродействие не получается. На днях я смог достичь 2-х кратного увеличения производительности одного из критически важных участков кода просто заменив использование двух разных буферов одним большим буфером, в по которому, не пересекаясь двигаются два независимых указателя. И режим оптимизации (простой /O2) не изменялся. Пожалуйста, c-smile, не принимайте эти слова, как сомнения в вашей компетенции. Это просто ремарка, о том, что иногда увеличения производительности можно добиться сменой алгоритма, а не параметра оптимизации.

Спасибо за ваш пример. Но как и пример What-а

Автор: What
Дата: 18.01.05

его можно считать очень платформенно-зависимым. Ведь вы из-за соображений производительности отказались от использования штатных примитивов синхронизации (критические секции или mutex-а), а сделали свои. И естественно, были вынуждены использовать volatile, поскольку в отсутствии обращений к внешним функциям ничего не запрещало компилятору "оптимизировать" работу с переменными.

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

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

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

>>> Прохождение sequence point отнюдь не гарантирует, что состояния всех объектов в этой точке будут непременно отражены в памяти — это гарантируется только для volatile-объектов.

ME>>Это не гарантируется большинством современных процессоров.

CS>Т.е. ты утверждаешь что в "большинстве современных процессоров" нет операции
CS>записи регистра в память? Или я не понял чего.

Эта операция необходима, но не достаточна. Из того, что процессор записал регистр в память не следует, что остальные процессоры
сразу ее прочитают.

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

ME>Вобщем, все вдумчиво читаем.

Вот еще
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1738.pdf
сжато, но есть ответы (или хотя бы намеки) на некоторые вопросы

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

CS>Знаешь, Макс, в моем багаже законченных продуктов
CS>есть например специализированный FTP сервер который работает без перезагрузки машины
CS>уже 14 месяцев с очень хорошим трафиком. Это я к тому что я примерно представляю как программировать multithreaded applications.

CS>И кстати обрати внимание что тебе здесь оппонируют люди которые *реально* занимаются multithreading. emusic (респект) например.

Ну вот, уже и до этого дошло.
Для того, чтобы я не показался случайным в multithreading человеком, который по незнанию выступает заодно с MaximE, хочу сказать, что в нашей компании эксплуатируется несколько программных комплексов, которые исключительно на многопоточности и работают. Где потоки готовят данные для других потоков, передают их через очереди сообщений, результаты обработки подхватывают третьи потоки, все это фиксируется/транслируется четвертыми потоками и т.д. Короче поток на потоке и потоком погоняет. Все это работает 24x7, уже не первый год, с остановками только на переконфигурирование. На платформах Windows и Linux, готовимся к переходу на HPNonStop. Некоторые из этих комплексов обрабатывают более миллиона транзакций в месяц. И все это на собственных библиотеках поддержки многопоточности.

Я действительно не эрудированный человек, много не знаю, в разработке pthreads или подобных системных вещей не участвовал, со стандартом C++ знаком поверхносно и вообще работа задавила, учиться некогда. Но с многопоточностью сталкиваюсь каждый день. И пока не видел, чтобы мои действия без volatile приводили к проблемам. Но если вероятность этих проблем есть, даже с соблюдением таких методов предосторожности, как синхронизирующие примитивы и нормального уровня оптимизация, то хотелось бы сделать правильные выводы.

Пока я вижу две точки зрения:

1. volatile нужен, т.к. в стандарте C++ не определено поведение в многопоточности. Поэтому компилятор имеет право проводить агрессивную оптимизацию. Поэтому, если не объявить переменную volatile, новое значение этой переменной из другого потока можно не увидеть, т.к. ее значение может быть закэшированно. Однако, есть "внешние вызовы", которые могут быть с побочными эффектами. Из-за них компилятор не использует черезмерную агрессивную оптимизацию (если его об этом не просят). Но следует считаться с тем, что грядут очень умные компиляторы и линкеры, которые способны прооптимизировать весь код, даже тот, который находиться в obj, static-lib и dll. А есть еще SMP-архитектуры, хитрые процессоры с переупорядочением инструкций и спекулятивными вычислениями, предсказаниями ветвлений и т.д. Получается, что без volatile вообще /censored/!

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

Но, и это очень большое но:

2. Мультипоточный код без volatile работает. Прекрасно работает. На разных платформах и разных поколениях разных комиляторов.

Это я бы назвал практической точкой зрения. С ней бесполезно спорить, т.к. это факт.

Соответственно, истина где-то в стороне от этих двух точек зрения.

И я бы хотел надеяться, что сработает закон "покупатель всегда прав". Если мне будут предлагать купить компилятор, который за счет глобальной оптимизации увеличит производительность моих программ вдвое, но при этом мне придется переписывать, перетестировать уже готовые приложения, то я, вероятно, скажу нет, не куплю. Т.к. дешевле купить вдвое более мощную платформу, чем переписать уже существующий код. И если мне говорят, что в стандарте ничего про многопоточность не сказано и, поэтому нужно использовать volatile, то я скажу: "А стандарт-то дырявый! Сделайте новый стандарт. В котором бы использование volatile не требовалось бы. Иначе я ваш язык использовать не буду и компиляторы покупать не буду, т.к. я покупатель. Я должен быть прав /какой знак здесь поставить, восклицательный или вопросительный/".


Пора на этом мое участие в этой ветке форума заканчивать, время дорого, а консенсус здесь невозможен.
Спасибо всем высказавшимся и предоставившим свои примеры.

---
P.S.

MaximE, мы то знаем, что мы правы

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

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

AS>>V2. Переменная объявлена не как volatile. Соотв, параметры InterlockedXxx без volatile (например, как это было в PSDK 2-х летней давности. Теперь это не так и вынуждает программистов использовать volatile для этих функций.

A>С какой радости? Преобразования указателей от менее cv-квалифицированных к более cv-квалифицированным происходят неявно.

LONG InterlockedExchange(
  LONG volatile* Target,
  LONG Value
);

Указатель здесь не volatile. Он всего-лишь указывает на LONG volatile.
Здесь это не страшно, но если нужно не только LONG значение менять, но и указатель иногда перекидывать на другое значение, то надо делать так:

LONG volatile* volatile p;

Но здесь одним вызовом InterlockedExchange уже не обойдешься.

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

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

A>>Кстати, конкретный вопрос. Назовите тот библиотечный файл, в котором "сидит" тело функции WaitForSingleObject.

CS>Для с++ "тело" этой функции сидит в

CS>

CS> Windows NT/2000/XP: Included in Windows NT 3.1 and later.
CS> Windows 95/98/Me: Included in Windows 95 and later.
CS> Header: Declared in Winbase.h; include Windows.h.
CS> Library: Use Kernel32.lib.

Там сидит шлюз на неё. Тело сидит в kernek32 или ntdll, смотря что за система.

CS>>Для с++ "тело" этой функции сидит в

CS>>

CS>> Windows NT/2000/XP: Included in Windows NT 3.1 and later.
CS>> Windows 95/98/Me: Included in Windows 95 and later.
CS>> Header: Declared in Winbase.h; include Windows.h.
CS>> Library: Use Kernel32.lib.

А>Там сидит шлюз на неё. Тело сидит в kernek32 или ntdll, смотря что за система.

Хотел бы я видеть систему, где эта функция в ntdll.dll

На самом деле, в lib в данном случае лишь указания линковщику на то, в какой dll находится эта функция + ее название\ord. Так что без дополнительных телодвижений распарсить тело функции действительно сложно — да и не нужно, оно ж зависит от версии системы. Так что, конечно, в этом случае компилятор обязан следовать своему внутреннему описанию побочных эффектов данной функции (помимо изменяемых регистров, которые следуют из соглашений вызова), либо, если это нужно, предполагать наихудший вариант. Кстати, интересной мыслью было бы размещать такую информацию непосредственно в lib файлах.

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

CS>>>Для с++ "тело" этой функции сидит в

CS>>>

CS>>> Windows NT/2000/XP: Included in Windows NT 3.1 and later.
CS>>> Windows 95/98/Me: Included in Windows 95 and later.
CS>>> Header: Declared in Winbase.h; include Windows.h.
CS>>> Library: Use Kernel32.lib.

А>>Там сидит шлюз на неё. Тело сидит в kernek32 или ntdll, смотря что за система.

AS>Хотел бы я видеть систему, где эта функция в ntdll.dll

Мои извинения, спутал с Enter/LeaveCriticalSection. WFSO реализована в kernel32.

AS>На самом деле, в lib в данном случае лишь указания линковщику на то, в какой dll находится эта функция + ее название\ord. Так что без дополнительных телодвижений распарсить тело функции действительно сложно — да и не нужно, оно ж зависит от версии системы. Так что, конечно, в этом случае компилятор обязан следовать своему внутреннему описанию побочных эффектов данной функции (помимо изменяемых регистров, которые следуют из соглашений вызова), либо, если это нужно, предполагать наихудший вариант. Кстати, интересной мыслью было бы размещать такую информацию непосредственно в lib файлах.

А>>>Там сидит шлюз на неё. Тело сидит в kernek32 или ntdll, смотря что за система.

AS>>Хотел бы я видеть систему, где эта функция в ntdll.dll

А>Мои извинения, спутал с Enter/LeaveCriticalSection. WFSO реализована в kernel32.

Нет, там тоже ее тела нет. Ее тело (в случае виннт) живет в ntoskrn. В kernel32 и в ntdll — переходники. В kernel32 это обычная заглушка, а в ntdll — шлюз. И Enter\LeaveCriticalSection тоже на самом деле ведет в итоге в ntdll, но в отличие от, реализована в ntdll.dll (RtlEnter\RtlLeaveCriticalSection)

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

ОК.

Я так понимаю что потребности в interlocked* у вас в проекте просто не возникало...
Т.е. вы обходитесь примитивами синхронизации верхнего уровня.

давай я еще раз повторю из моего предыдущего сообщения.

Я не говорю что без volatile нельзя написать multihreading код.
Я говорю — volatile есть, описан в стандарте языка, поддерживается нужными мне компиляторами и реально помогает мне писать эффективный код (простой, надежный, human readable).

Без volatile — можно, если производительность кода не есть mission critical
или если достаточно примитивов и barriers уже кем-то написаныых с пом. того же volatile
http://docs.hp.com/en/B3909-90003/apas04.html

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

>> Вопрос вызван тем, что у Рихтера прочитал, что если глобальная переменная используется
>> разными потоками, то она обязана быть volatile. Вот меня и рабирают сомнения нужно ли
>> тоже самое делать для переменных(членов) класса.

ME>Рихтер ошибался.
Без коментариев

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

Валерий.
ЗЫ. Это объяснение почему поставил минус.

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

>>>> На моей задаче aliasing оптимизация дает 16% прирост производительности. Поэтому без этой оптимизации я даже и не компилирую.
>>>> http://terrainformatica.com/htmlayout

ME>С этой опцией у тебя даже однопоточные программы будут глючить — поэтому тебе нужен volatile.

Это если подходить к делу без ума.

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

E>Здравствуйте, c-smile, Вы писали:

E>Спасибо за ваш пример. Но как и пример What-а

Автор: What
Дата: 18.01.05

его можно считать очень платформенно-зависимым. Ведь вы из-за соображений производительности отказались от использования штатных примитивов синхронизации (критические секции или mutex-а), а сделали свои. И естественно, были вынуждены использовать volatile, поскольку в отсутствии обращений к внешним функциям ничего не запрещало компилятору "оптимизировать" работу с переменными.

Я использую штатные там где это действительно надо.

namespace tool 
{

#ifdef WIN32
class mutex { 
    CRITICAL_SECTION cs;
 public:
    void lock() { 
        EnterCriticalSection(&cs);
    } 
    void unlock() {
        LeaveCriticalSection(&cs);
    } 
    mutex() { 
        InitializeCriticalSection(&cs);
    }   
    ~mutex() { 
        DeleteCriticalSection(&cs);
    }
};

struct event 
{ 
    HANDLE h;

    event() { 
        h = CreateEvent(NULL, FALSE, FALSE, NULL);
    }
    ~event() { 
        CloseHandle(h);
    }
    void signal() { 
        SetEvent(h);
    }
    void pulse() { 
        PulseEvent(h);
    }

    void wait(mutex& m) { 
        m.unlock();
        WaitForSingleObject(h, INFINITE);
        m.lock();
    }
    void wait() { 
        WaitForSingleObject(h, INFINITE);
    }
    
};

#else // pthreads

class mutex { 
    int             count;
    pthread_t       owner;
    pthread_mutex_t cs;

    friend class event_t;
 public:
    void lock() { 
    pthread_t self = pthread_self();
    if (owner != self) { 
        pthread_mutex_lock(&cs); 
        owner = self;
    }
    count += 1;
    }
    void unlock() { 
    assert(pthread_self() == owner);
    if (--count == 0) {
        owner = 0;
        pthread_mutex_unlock(&cs);
    } 
    }
    mutex() { 
    pthread_mutex_init(&cs, NULL);
    }   
    ~mutex() { 
    pthread_mutex_destroy(&cs);
    }
};

class event { 
    pthread_cond_t cond;

   public:
    event() { 
    pthread_cond_init(&cond, NULL);
    }
    ~event() { 
    pthread_cond_destroy(&cond);
    }
    void signal() { 
    pthread_cond_signal(&cond);
    }
    void wait(mutex_t& m) { 
    pthread_t self = pthread_self();
    assert(m.owner == self && m.count == 1);
    m.count = 0;
    m.owner = 0;
    pthread_cond_wait(&cond, &m.cs);
    m.count = 1;
    m.owner = self;
    }
};

#endif

Код практически 1 в 1 нагло заимствован из SAL Кости Книжника.

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

ME>

Док-ция к процессору, здесь — IA-32 Intel® Architecture Software Developer's Manual Volume 3: System Programming Guide. Здесь нам черным по белому пишут в §7.2.4:
ME>

ME>It is recommended that software written to run on Pentium 4, Intel Xeon, and P6 family processors assume the processor-ordering model or a weaker memory-ordering model. The Pentium 4, Intel Xeon, and P6 family processors do not implement a strong memory-ordering model, except when using the UC memory type. Despite the fact that Pentium 4, Intel Xeon, and P6 family processors support processor ordering, Intel does not guarantee that future processors will support this model. To make software portable to future processors, it is recommended that operating systems provide critical region and resource control constructs and API s (application program interfaces) based on I/O, locking, and/or serializing instructions be used to synchronize access to shared areas of memory in multiple-processor systems. Also, software should not depend on processor ordering in situations where the system hardware does not support this memory-ordering model.

Ты сам вообще внимательно прочел что написано?

Группа функций Interlocked* как раз является импелементацией "...and/or serializing instructions be used..."

Производитель компилятора тебе сказал что он хочет видеть переменную отдаваемую в InterlockedIncrement
объявленную как volatile. Ты также знаешь что оптимизатор будет относится к чтению volatile переменных с определенным
пиететом.

Это твое личное дело слушать рекомендации или нет.

Только не говори что "volatile вредит". Встречное предложение: покажи мне реальный код где volatile вредно. Или не portable.
Если не portable, то пожалуйста приведи portable механизмы синхронизации.

alnsn wrote:

> Здравствуйте, MaximE, Вы писали:
>
> ME>Вобщем, все вдумчиво читаем.
>
> Вот еще
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1738.pdf
> сжато, но есть ответы (или хотя бы намеки) на некоторые вопросы

И еще Memory model for multithreaded C++

--
Maxim Yegorushkin

c-smile wrote:

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

Док-ция к процессору, здесь — IA-32 Intel® Architecture Software Developer's Manual Volume 3: System Programming Guide. Здесь нам черным по белому пишут в §7.2.4:
> ME>

> ME>It is recommended that software written to run on Pentium 4, Intel Xeon, and P6 family processors assume the processor-ordering model or a weaker memory-ordering model. The Pentium 4, Intel Xeon, and P6 family processors do not implement a strong memory-ordering model, except when using the UC memory type. Despite the fact that Pentium 4, Intel Xeon, and P6 family processors support processor ordering, Intel does not guarantee that future processors will support this model. To make software portable to future processors, it is recommended that operating systems provide critical region and resource control constructs and API s (application program interfaces) based on I/O, locking, and/or serializing instructions be used to synchronize access to shared areas of memory in multiple-processor systems. Also, software should not depend on processor ordering in situations where the system hardware does not support this memory-ordering model.
> ME>

>
> Ты сам вообще внимательно прочел что написано?
>
> Группа функций Interlocked* как раз является импелементацией "...and/or serializing instructions be used..."
>
> Производитель компилятора тебе сказал что он хочет видеть переменную отдаваемую в InterlockedIncrement объявленную как volatile.

В документации это желание/требование никак не выражено.

size_t strlen(char const*);

Значит ли это объявленние ф-ции, что ее автор "хочет видеть" только константные строки? Или это значит, что автору наплевать, константная ли строка?

Ключевых слов C++ недостаточно, чтобы выразить только ими без какой либо дополнительной док-ции требования, гарантии и ограничения функции.

> Ты также знаешь что оптимизатор будет относится к чтению volatile переменных с определенным пиететом.

Я не буду использовать volatile, пока мне четко не скажут в док-ции к компилятору/api, что это необходимо.

---

Больше ничего нового я в ближайшее время здесь не скажу.

--
Maxim Yegorushkin

Posted via RSDN NNTP Server 1.9

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

ME>Я не буду использовать volatile, пока мне четко не скажут в док-ции к компилятору/api, что это необходимо.

Документация к компилятору Visual C++

int volatile nVint;

Objects declared as volatile are not used in optimizations because their value can change at any time. The system always reads the current value of a volatile object at the point it is requested, even if the previous instruction asked for a value from the same object. Also, the value of the object is written immediately on assignment.

c-smile wrote:

> Здравствуйте, MaximE, Вы писали:
>
> ME>Я не буду использовать volatile, пока мне четко не скажут в док-ции к компилятору/api, что это необходимо.
>
> Документация к компилятору Visual C++
>
>

> int volatile nVint;
>
> Objects declared as volatile are not used in optimizations because their value can change at any time. The system always reads the current value of a volatile object at the point it is requested, even if the previous instruction asked for a value from the same object. Also, the value of the object is written immediately on assignment.

Андрей, я подразумеваю, что русский мы понимаем на равных, и английский мы знаем достаточно, хотя бы для того, чтобы после фразы "would you like to go out with me tonight?" на следущее утро также накормить девушку завтраком?

Так вот, где в приведенной тобой цитате сказано

... пока мне четко не скажут в док-ции к компилятору/api, что это необходимо

--
Maxim Yegorushkin

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

>>

>> int volatile nVint;
>>
>> Objects declared as volatile are not used in optimizations because their value can change at any time. The system always reads the current value of a volatile object at the point it is requested, even if the previous instruction asked for a value from the same object. Also, the value of the object is written immediately on assignment.

ME>Андрей, я подразумеваю, что русский мы понимаем на равных, и английский мы знаем достаточно, хотя бы для того, чтобы после фразы "would you like to go out with me tonight?" на следущее утро также накормить девушку завтраком?

ME>Так вот, где в приведенной тобой цитате сказано
ME>

ME>... пока мне четко не скажут в док-ции к компилятору/api, что это необходимо

OK. Let's rephrase this as: If you want to assure the value of variable to appear at its memory location upon assignment you must
declare this variable as a volatile. According to VC++ documentation this is the only legal way to exclude assignment to it from any optimizations.

Это если следовать формальной логике.

Ты пойми, никакого формального же описания "барьеров" в документации VC++ просто нет. Собственно как и ни в каком другом компиляторе.
Единственное что есть это volatile.

"Барьер" это некая абстракция верхнего уровня которая имплементируется везде где я только это видел на volatile переменных.

Вот например свежий патч к GCC по поводу создания барьеров:

My patch for PR c++/13684 implemented thread-safe initialization of C++
static local variables, using the double-checked locking pattern:

http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01888.html

Не знаю, как соотносятся volatile у C++ и С#, но вот из документации FW 2.0 SDK:

The volatile keyword indicates that a field can be modified in the program by something such as the operating system, the hardware, or a concurrently executing thread.
.......

The system always reads the current value of a volatile object at the point it is requested, even if the previous instruction asked for a value from the same object. Also, the value of the object is written immediately on assignment.

The volatile modifier is usually used for a field that is accessed by multiple threads without using the lock statement to serialize access. Using the volatile modifier ensures that one thread retrieves the most up-to-date value written by another thread.