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

V>>Сформулируй свои возражения предметно, плиз, я тогда с ними или соглашусь, или опровергну.
·>Какие возражения?

Свои, ес-но.
От тебя пока прёт пена: "Я не согласен, потому что не согласен".
Пояснить не можешь, так и запишем.
А пролетарское твоё чутьё никому не интересно.


·>Ты заявил "многопоточность в языке появилось давно"

Дословно было сказано:

Это артефакты Си/Linux, где Си разрабатывался для целей написания многопоточной операционки.

·>но своё заявление ничем не подтвердил.

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


·>Так что либо признавайся, что ты насочинял глупостей

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


V>>1. Покажи, какие твои цитаты из стандарта я повторяю?
·>

sig_atomic_t это для "asynchronous interrupts made by signals"

Это не цитата из стандарта, это искажение информации, т.е. роспись в неумении читать.
Цитата там такова:

sig_atomic_t — an integer type which can be accessed as an atomic entity even in the presence of asynchronous interrupts made by signals.

Перевод на русский язык требуется?

А тут:

Until C++11, which introduced std::atomic and std::atomic_signal_fence, about the only thing a strictly conforming program could do in a signal handler was to assign a value to a volatile static std::sig_atomic_t variable and promptly return.

?

V>>2. Чем не устроило объяснение модели вытесняющей многопоточности через механизм прерываний? Поясни ошибки в моём изложении.
·>Тем что это объяснение у тебя никто не просил и оно не в тему.

Насчёт "никто не просил" — у тебя забыли поинтересоваться.

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

Одинаковый аппаратный механизм означает одинаковые требования к языку и алгоритмам поверх аппаратуры.
Походу, с понимаем проблемки.


V>>Если алгоритм не требует какой-либо сильной модели памяти, т.е. достаточно модели "relaxed", то достаточно простой атомарности операций чтения/записи переменной.
·>Заблуждение.

Дык, вперёд! Раскрой суть заблуждения!


·>Или ссылки на спеку в студию.

Спеку чего? ))
Какого-нить алгоритма, для которого достаточно relaxed-модели памяти?
Проверка в цикле некоей переменной пойдёт:

static volatile sig_atomic_t flag = 0;

void sig_handler(int signum) {
    if(signum == SIGPIPE)
        flag = 1;
}

...
while(!flag)
    printSomethingToStdout();

?

Через sigaction можно подписаться на более подробную сигнатуру, например, можно узнать, что навернулся именно stdout, а не любой другой pipe.

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

V>>Сформулируй свои возражения предметно, плиз, я тогда с ними или соглашусь, или опровергну.
·>Какие возражения?

Свои, ес-но.
От тебя пока прёт пена: "Я не согласен, потому что не согласен".
Пояснить не можешь, так и запишем.
А пролетарское твоё чутьё никому не интересно.


·>Ты заявил "многопоточность в языке появилось давно"

Дословно было сказано:

Это артефакты Си/Linux, где Си разрабатывался для целей написания многопоточной операционки.

·>но своё заявление ничем не подтвердил.

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


·>Так что либо признавайся, что ты насочинял глупостей

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


V>>1. Покажи, какие твои цитаты из стандарта я повторяю?
·>

sig_atomic_t это для "asynchronous interrupts made by signals"

Это не цитата из стандарта, это искажение информации, т.е. роспись в неумении читать.
Цитата там такова:

sig_atomic_t — an integer type which can be accessed as an atomic entity even in the presence of asynchronous interrupts made by signals.

Перевод на русский язык требуется?

А тут:

Until C++11, which introduced std::atomic and std::atomic_signal_fence, about the only thing a strictly conforming program could do in a signal handler was to assign a value to a volatile static std::sig_atomic_t variable and promptly return.

?

V>>2. Чем не устроило объяснение модели вытесняющей многопоточности через механизм прерываний? Поясни ошибки в моём изложении.
·>Тем что это объяснение у тебя никто не просил и оно не в тему.

Насчёт "никто не просил" — у тебя забыли поинтересоваться.

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

Одинаковый аппаратный механизм означает одинаковые требования к языку и алгоритмам поверх аппаратуры.
Походу, с понимаем проблемки.


V>>Если алгоритм не требует какой-либо сильной модели памяти, т.е. достаточно модели "relaxed", то достаточно простой атомарности операций чтения/записи переменной.
·>Заблуждение.

Дык, вперёд! Раскрой суть заблуждения!


·>Или ссылки на спеку в студию.

Спеку чего? ))
Какого-нить алгоритма, для которого достаточно relaxed-модели памяти?
Проверка в цикле некоей переменной пойдёт:

static volatile sig_atomic_t flag = 0;

void sig_handler(int signum) {
    if(signum == SIGPIPE)
        flag = 1;
}

...
while(!flag)
    printSomethingToStdout();

?

Через sigaction можно подписаться на более подробную сигнатуру, например, можно узнать, что навернулся именно stdout, а не любой другой pipe.