Глядим коротко, что нас, пользователей С/С++, ждёт нового в С++0x относительно поддержки многопоточности:
http://www.justsoftwaresolutions.co.uk/files/future_of_concurrency.pdf

Описываются:
— Модель памяти (memory model)
— Атомарные операции (atomics)
— Локальные для потока переменные (thread-local static variables)
— Потоки (threads)
— Мьютексы (mutexes)
— Условные перменные (condition variables)
— Однократная инициализация (one-time initialization)
— Асинхронные операции (futures)

Так же описывается, что нас ждёт в более отдалённом будущем (в boost, будем надеятся значительно раньше):
— Пулы потоков (thread pools)
— Многопоточные контейнеры (concurrent_queue, concurrent_stack и т.д.)
— Параллельные алгоритмы (parallel_for, parallel_sort и т.д.)
— Транзакционная память и автоматическое распараллеливание (software transactional memory, auto-parallelisation)

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

R>Глядим коротко, что нас, пользователей С/С++, ждёт нового в С++0x относительно поддержки многопоточности:


Недавно был вопрос по поводу реализации простейшего паттерна в С++:
http://gzip.rsdn.ru/forum/message/2909622.1.aspx

Автор: NightWind
Дата: 09.04.08

Реализация достаточно не тривиальная + не портируемая:
http://gzip.rsdn.ru/forum/message/2911323.1.aspx

Автор: remark
Дата: 10.04.08

На С++0х это будет реализовываться таким (уже портабельным) способом:

#include <cstdatomic>
#include <vector>
#include <iostream>

std::atomic_bool g_data_init;
std::vector<int> g_data

void tread1()
{
    g_data.push_back(0);
    g_data_init.store(true, std::memory_model_release);
}

void tread2()
{
    while (false == g_data_init.load(std::memory_model_acquire)) {}
    std::cout << g_data[0];
}

R>

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

R>Глядим коротко, что нас, пользователей С/С++, ждёт нового в С++0x относительно поддержки многопоточности:

а интересно, будет ли вообще С++0x ?
просто "что нас ждёт нового в С++0x" — такая басянистая фраза, что уже не помню она появилась раньше или "что нас ждёт нового в Duke Nukem Forever"

может правильно надо писать "что нас ждёт нового в С++хx" ?

Здравствуйте, Аноним, Вы писали:

R>>Глядим коротко, что нас, пользователей С/С++, ждёт нового в С++0x относительно поддержки многопоточности:

А>а интересно, будет ли вообще С++0x ?

C++09. И нииcensored.

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

RO>C++09. И нииcensored.

ну да, последний шанс для стандарта 0х
а значит принимать его прийдётся в спешке

Я так понимаю, ожидания нескольких событий ( по типу WaitForMultipleObjects ) не будет ?


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

R>Глядим коротко, что нас, пользователей С/С++, ждёт нового в С++0x относительно поддержки многопоточности:
R>http://www.justsoftwaresolutions.co.uk/files/future_of_concurrency.pdf

R>Описываются:
R> — Модель памяти (memory model)
R> — Атомарные операции (atomics)
R> — Локальные для потока переменные (thread-local static variables)
R> — Потоки (threads)
R> — Мьютексы (mutexes)
R> — Условные перменные (condition variables)
R> — Однократная инициализация (one-time initialization)
R> — Асинхронные операции (futures)

R>Так же описывается, что нас ждёт в более отдалённом будущем (в boost, будем надеятся значительно раньше):
R> — Пулы потоков (thread pools)
R> — Многопоточные контейнеры (concurrent_queue, concurrent_stack и т.д.)
R> — Параллельные алгоритмы (parallel_for, parallel_sort и т.д.)
R> — Транзакционная память и автоматическое распараллеливание (software transactional memory, auto-parallelisation)


R>

Здравствуйте, Аноним, Вы писали:

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

R>>Глядим коротко, что нас, пользователей С/С++, ждёт нового в С++0x относительно поддержки многопоточности:

А>а интересно, будет ли вообще С++0x ?
А>просто "что нас ждёт нового в С++0x" — такая басянистая фраза, что уже не помню она появилась раньше или "что нас ждёт нового в Duke Nukem Forever"

А>может правильно надо писать "что нас ждёт нового в С++хx" ?


Это ещё более басянистая фраза


Если действительно интрересно, то попробуй последить за работой WG21 — там всё открыто.

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on RSDN, USENET and in e-mail?

А как её реализовывать без поддержки ОС?

Хотя бы потому что в POSIX её нет.

Я думаю, что нет.

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

ST>Я так понимаю, ожидания нескольких событий ( по типу WaitForMultipleObjects ) не будет ?

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

R>>Глядим коротко, что нас, пользователей С/С++, ждёт нового в С++0x относительно поддержки многопоточности:
R>>http://www.justsoftwaresolutions.co.uk/files/future_of_concurrency.pdf

R>>Описываются:
R>> — Модель памяти (memory model)
R>> — Атомарные операции (atomics)
R>> — Локальные для потока переменные (thread-local static variables)
R>> — Потоки (threads)
R>> — Мьютексы (mutexes)
R>> — Условные перменные (condition variables)
R>> — Однократная инициализация (one-time initialization)
R>> — Асинхронные операции (futures)

R>>Так же описывается, что нас ждёт в более отдалённом будущем (в boost, будем надеятся значительно раньше):
R>> — Пулы потоков (thread pools)
R>> — Многопоточные контейнеры (concurrent_queue, concurrent_stack и т.д.)
R>> — Параллельные алгоритмы (parallel_for, parallel_sort и т.д.)
R>> — Транзакционная память и автоматическое распараллеливание (software transactional memory, auto-parallelisation)


R>>

А как же select?

R>Хотя бы потому что в POSIX её нет.

R>Я думаю, что нет.

ST>>Я так понимаю, ожидания нескольких событий ( по типу WaitForMultipleObjects ) не будет ?

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

RO>А как же select?

AFAIK, он может значительно меньше чем WFMO.

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

RO>>А как же select?

_>AFAIK, он может значительно меньше чем WFMO.

Что именно не умеет select(2) такого, что умеет WaitForMultipleObjects? (Впрочем, обе они кривые, хотя бы потому, что у них слишком сильное ограничение на количество событий.)

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

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

RO>>>А как же select?

_>>AFAIK, он может значительно меньше чем WFMO.

RO>Что именно не умеет select(2) такого, что умеет WaitForMultipleObjects? (Впрочем, обе они кривые, хотя бы потому, что у них слишком сильное ограничение на количество событий.)
Признаться не линуксоид я ни разу, но когда рассказывал линуксоидам что может WFMO они кусали локти (не надо холивара! у POSIX есть свои плюсы)
Потоков дожидаться по хендлу, процессов.

The WaitForMultipleObjects function can specify handles of any of the following object types in the lpHandles array:

Change notification
Console input
Event
Job
Memory resource notification
Mutex
Process
Semaphore
Thread
Waitable timer

Добавлю что всех, или любого. В любых комбинациях

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

RO>>Что именно не умеет select(2) такого, что умеет WaitForMultipleObjects? (Впрочем, обе они кривые, хотя бы потому, что у них слишком сильное ограничение на количество событий.)
_>Признаться не линуксоид я ни разу, но когда рассказывал линуксоидам что может WFMO они кусали локти :) (не надо холивара! у POSIX есть свои плюсы)
_>Потоков дожидаться по хендлу, процессов.
_>Добавлю что всех, или любого. В любых комбинациях

Понятно. Это древний флеймообразователь. Основные аргументы — «а мы вот так умеем» и «вот так — это антипаттерн».

Я считаю, что идея WFMO изначально нехороша. Как кто-то где-то сказал, мьютексы, условия и т. п. — это кровати, в которых спят потоки. А спать надлежит в одной кровати, если только речь не об экс-президенте США.

Подход WFMO — вот у меня есть событие, я его выставлю, когда произойдет что-нибудь интересное (ожидающий поток выбирает нужные ему события и блокируется).
Идеологически правильный подход — на тебе коллбек, когда что-нибудь интересное произойдет, звякни (а коллбек дернет условие на стороне ожидающего потока).

Впрочем, функция ожидания одного из многих событий тоже нужна — в ситуациях, когда нельзя/сложно напрямую договориться с генератором этих событий (например, когда они сидят в ядре). Поэтому и существует select (и более продвинутые разновидности вроде epoll и kqueue). Собственно, используя асинхронный В/В, можно даже здесь отказаться от подобных функций, но такое решение попросту сильно потеряет в эффективности.

Здравствуйте, Аноним, Вы писали:

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

RO>>C++09. И нииcensored.

А>ну да, последний шанс для стандарта 0х
А>а значит принимать его прийдётся в спешке

Вообе-то есть четкий график, когда и что.
И, как жалуется Строуструп, если бы не бюрократия, которая царит в ISO, стандарты бы принимались гораздо быстрее.
По его оценкам, стандарт будет готов осенью 2008-го года (финальная версия), а потом около года проваландается по инстанциям до официального издания.
Т.е. к моменту официального выхода комитет уже год как будет работать над TR2.

You will always get what you always got
  If you always do  what you always did

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

RO>Я считаю, что идея WFMO изначально нехороша. Как кто-то где-то сказал, мьютексы, условия и т. п. — это кровати, в которых спят потоки. А спать надлежит в одной кровати, если только речь не об экс-президенте США.

RO>Подход WFMO — вот у меня есть событие, я его выставлю, когда произойдет что-нибудь интересное (ожидающий поток выбирает нужные ему события и блокируется).
RO>Идеологически правильный подход — на тебе коллбек, когда что-нибудь интересное произойдет, звякни (а коллбек дернет условие на стороне ожидающего потока).


А почему первый подход плохой?

RO>Я считаю, что идея WFMO изначально нехороша. Как кто-то где-то сказал, мьютексы, условия и т. п. — это кровати, в которых спят потоки. А спать надлежит в одной кровати, если только речь не об экс-президенте США.
Не всё понял. Тебе не нравится то что WFMO позволяет блокироваться не только на потоках ввода-вывода, а ещё и на мьютексах, семафорах и т.п.? Или не нравится вообще подход "ждать более чем один обьект синхронизации"?

RO>Подход WFMO — вот у меня есть событие, я его выставлю, когда произойдет что-нибудь интересное (ожидающий поток выбирает нужные ему события и блокируется).
RO>Идеологически правильный подход — на тебе коллбек, когда что-нибудь интересное произойдет, звякни (а коллбек дернет условие на стороне ожидающего потока).
Хм. А в чём разница? Реально в прикладном коде это всё равно будет обёрнуто в реактор (который к тому же абстрагируется от того что там под капотом — WFMO или select) который в итоге дёрнет именно коллбек с тем контекстом который с ним ассоциирован. А отдавать настоящие колбеки в функцию синхронизации... Не знаю, мне не нравится Ну или по крайней мере, не вижу явных преимуществ.

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

RO>>Подход WFMO — вот у меня есть событие, я его выставлю, когда произойдет что-нибудь интересное (ожидающий поток выбирает нужные ему события и блокируется).
RO>>Идеологически правильный подход — на тебе коллбек, когда что-нибудь интересное произойдет, звякни (а коллбек дернет условие на стороне ожидающего потока).

R>А почему первый подход плохой?

(Главное) Выставляет наружу объекты синхронизации.
Сигналит даже тогда, когда никто не слушает.
Требует WaitForMultipleObjects или велосипед.
Поди разбери, что именно сработало (недостаток именно WFMO, а не подхода).
Строгие ограничения на количество объектов (недостаток именно WFMO, а не подхода).
Относительный таймаут (недостаток именно WFMO, а не подхода).

Я поискал немного по RSDN, все увиденные мной упоминания WFMO, кроме одного, были связаны с ожиданием завершения N-ного числа потоков. Хотя это то же самое, что дожидаться завершения по одному.

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

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

RO>>Я считаю, что идея WFMO изначально нехороша. Как кто-то где-то сказал, мьютексы, условия и т. п. — это кровати, в которых спят потоки. А спать надлежит в одной кровати, если только речь не об экс-президенте США.
L>Тебе не нравится то что WFMO позволяет блокироваться не только на потоках ввода-вывода, а ещё и на мьютексах, семафорах и т.п.?

Это может не нравиться только Шеридану :-)

L>Или не нравится вообще подход "ждать более чем один обьект синхронизации"?

А вот подход, наверное, неправильный.

RO>>Подход WFMO — вот у меня есть событие, я его выставлю, когда произойдет что-нибудь интересное (ожидающий поток выбирает нужные ему события и блокируется).
RO>>Идеологически правильный подход — на тебе коллбек, когда что-нибудь интересное произойдет, звякни (а коллбек дернет условие на стороне ожидающего потока).
L>Хм. А в чём разница? Реально в прикладном коде это всё равно будет обёрнуто в реактор (который к тому же абстрагируется от того что там под капотом — WFMO или select) который в итоге дёрнет именно коллбек с тем контекстом который с ним ассоциирован. А отдавать настоящие колбеки в функцию синхронизации... Не знаю, мне не нравится :) Ну или по крайней мере, не вижу явных преимуществ.

Это немножко другое. select, poll, epoll, kqueue, IOCP — это демультиплексоры. Они выбирают подмножество интересных дескрипторов из (потенциально большого) множества.

Речь о (проблемном) подходе, в котором события, на которых можно блокироваться, выставляются как часть интерфейса.

L>>Хм. А в чём разница? Реально в прикладном коде это всё равно будет обёрнуто в реактор (который к тому же абстрагируется от того что там под капотом — WFMO или select) который в итоге дёрнет именно коллбек с тем контекстом который с ним ассоциирован. А отдавать настоящие колбеки в функцию синхронизации... Не знаю, мне не нравится Ну или по крайней мере, не вижу явных преимуществ.

RO>Это немножко другое. select, poll, epoll, kqueue, IOCP — это демультиплексоры. Они выбирают подмножество интересных дескрипторов из (потенциально большого) множества.
Так и WFMO — точно такой же демультиплексор, с чуть другим (даже не принципиально другим, а просто чуть другим) интерфейсом.

RO>Речь о (проблемном) подходе, в котором события, на которых можно блокироваться, выставляются как часть интерфейса.
Всё равно не пойму. При чём тут сам WFMO тогда? И что плохого в том что события выставляются как часть интерфейса? В грамотно спроектированной системе всё равно это будет в виде "вот это событие говорит о том что в очереди заданий появилось новое задание, а вот это говорит о том что нужно завершить работу и потушиться". Чем это принципиально отличается от "дёрни меня за эту функцию в случае 1, и вот за эту в случае 2"? Или я неправильно понял твою идею насчёт коллбеков?

Здравствуйте, Аноним, Вы писали:

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

RO>>C++09. И нииcensored.

А>ну да, последний шанс для стандарта 0х
А>а значит принимать его прийдётся в спешке

Ну почему же, может быть ещё С++0A, C++0B, C++0xDEADBEEF в конце концов.