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

E>>Вообще-то эра многопоточных приложений наступила давно.
M>Да не сказал бы. Даже серверные приложения зачастую не очень-то и масштабируемы, а мастшабируемых клиентских так и вообще еще почти нет.

Не факт, что проблемы маштабируемости напрямую связаны с архитектурой приложения. Здесь может быть масса факторов. Вот могу тебе пример из собственной предметной области привести.

Есть такой протокол, Short Message Peer-to-Peer (SMPP), для обеспечения обмена SMS-ами с SMS-центрами мобильных операторов. SMPP -- это компактный двоичный протокол, который подразумевает обмен пакетами (PDU) по одному TCP/IP каналу. Следовательно, пропускная способность SMPP-узла ограничивается либо пропускной способностью канала, либо возможностью софта по обработке данных. Ну вот представь себе, что через SMPP канал начнет идти 1000 транзакций в секунду. Это означает, что обработка одной транзакции должна занимать меньше миллисекунды, а это уже не слабый real-time. Но фишка в том, что балансировку здесь сделать сложно -- вся 1000 транзакций пойдет через один канал и придет в одну точку. Даже если эта точка будет load-balancer-ом, то еще нужно еще специальным образом реализовать, т.к. в SMPP есть свои заморочки с организацией сессий и пр. И представь себе софт, который разрабатывался в расчете на трафик в 10-20 транзакций, но на него стали сваливаться объемы в 100 раз большие (бизнес удачно пошел). Как его смаштабировать?

Сейчас кроме SMPP еще появился MMAP -- аналог SMPP, но на основе SOAP. Каждая отдельная транзакция в XML-е занимает гораздо больше места, чем в SMPP. Да еще HTTP в качестве транспорта. Жуть, как может показаться. А на самом деле, распараллеливание здесь делается ну просто на порядки проще. Хотя бы за счет того, что HTTP-load-balancer-ов навалом. И все, что нужно сделать -- это CGI (попросту говоря), который будет заниматься обработкой отдельных транзакций. А дальше -- ставь кластер из 10 машин, ставь туда web-сервер и распределяй по 100 транзакций на каждую машину. Особых проблем не видно.

А ведь все из-за чего -- из-за другого протокола.

M> И когда все поголовно сюда ломанутся, понадобятся совсем другие инструменты.

+1
Поскольку ручное управление потоками и их синхронизация удовольствие малоприятное, то да, для массового потребления придется создать простой, подходящий для 80% случаев инструмент. Но это совсем не значит, что те, кто сейчас разрабатывают многопоточные приложения, не пользуются соответствующими инструментами. Пользуются. Еще как пользуемся Вот только есть очень большое подозрение, что это не для массового потребления инструменты.

E>>Так что многопоточные приложения на C++ давно существуют и будут продолжать существовать
M>Также, как и однопоточные.

E>>А если один домен зависнет?
M>Честно говоря — не знаю. Зависнет — значит зависнет. Остальных это затронуть не должно. По идее.

Угу. Именно, что по идее.

M>Встречный вопрос — а если зависнет один из процессов?

Он просто прибивается. Скажем через kill -9 Остальные продолжают работать. Unix-овые системы уже лет двадцать так работают.