Многопоточность - панацея или криворукость monkey coder-ов из больших корпораций

Вопрос прост:
Зачем к примеру скайпу в режиме ожидания 90 потоков?
И зачем 60 потоков FireFox с одной открытой вкладкой?
Или аж 31 поток ЛАУНЧЕРУ World of Warships при ожидании нажатия кнопки старт?
Или 70 потоков рабочему столу?
Или 30 потоков закрытому Microsoft.Photos?
Или 19 потоков калькулятору. Там кнопок меньше чем потоков. Что в нем то параллелить?
И все это хозяйство на 4 ядра. Вопрос зачем? Чтобы таск свитчинг тормозил? Ведь 99% того на что вешают потоки еще лучше будет работать в псевдопараллельном режиме. Но это как понимаю мозгами шурупать надо над иерархиями и тп а не накатать кучу кривого кода в мертвом цикле и сунуть в поток.

0

Сообщение от Fulcrum_013 Если заметил цель приведенного примера подвесить ось любого суперкомпутера.

Я заметил что это твои жалкие попытки как-то сгладить свой конфуз. Я бы еще понял если бы ты задался целью грохнуть стек, а так твои оппытки просто упрутся в /proc/sys/kernel/threads-max (о чем ты конечно не знаешь) и дальше все ctreat'ы вернут фейл.

Сообщение от Fulcrum_013 И этот код это сделает

ага, насмешил

Сообщение от korvin_ в однопоточном коде достаточно бесконечного цикла

с парочкой volatile id

0

Сообщение от cybercitizen а так твои оппытки просто упрутся в /proc/sys/kernel/threads-max (о чем ты конечно не знаешь) и дальше все ctreat'ы вернут фейл.

Главное чтобы количество созданных было больше количества конвейеров.

0

Сообщение от Fulcrum_013 Главное чтобы количество созданных было больше количества конвейеров.

Главное что ты понятия не имеешь о работе программистом за пределами своей конуры. И поэтому создаешь такие тупые темы и посты.
Grep'нул firefox на строку "int main", 1300+ матчей.

0

Сообщение от cybercitizen Главное что ты понятия не имеешь о работе программистом за пределами своей конуры. И поэтому создаешь такие тупые темы и посты

Главное что имею понятие что работать программистом по найму - быть идиотом в квадрате. А мозгов нужный себе любимому софт делать хватает.

Добавлено через 1 минуту
А с количеством потоков у современного софта таки явный перебор.

Добавлено через 5 минут
К примеру для WinHTTPSendRequest и WinHTTPReceiveResponse каллбеки приходят в разных потоках для одного и того же запроса.

0

Сообщение от Fulcrum_013 Главное что имею понятие что работать программистом по найму - быть идиотом в квадрате

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

Сообщение от Fulcrum_013 А с количеством потоков у современного софта таки явный перебор.

Ты уже разобрался в исходном коде firefox?

0

Сообщение от cybercitizen Но очевидные плюсы в работе по найму есть, это колосальный опыт разработки информационных систем.

Этот опыт для 90% а то и 95% работающих типа программистами в СНГ вообще отсутствует. Опять же что понимать под информационной системой? Погонять данные туда-сюда от юзера в бд от бд к юзеру? Как раз и есть работа для монкей-кодеров. А по части именно обработки (серьезного обсчета) данных - то в СНГ это разве что в гейм-дизайне востребовано. А вот в этом плане - а именно алгоритмической обработки данных у меня побольше чем у очень многих.

Добавлено через 9 минут

Сообщение от cybercitizen Ты уже разобрался в исходном коде firefox?

Та нет по ходу пьессы WinHTTP API мучаю. Не хочет WebSocket пахать, хоть бери и в ручную обработчик протокола пиши блин.

Добавлено через 25 минут
А такое количество потоков по всей видимости обусловлено перебором с изоляторами на уровне API. т.е. как изолировать процесс 0-го кольца от процесса 3-его кольца так чтобы осталась возможность отправлять из 0-го кольца в 3-е не только мессаджи но и калбеки? Самый логичный способ - даем при запросе к 0-ому кольцу из 3-го буффер и паузнутый тред, состоящий из мертвого цикла - вызов каллбка, и пауза самого себя. Когда процесс 0-го кольца имеет что сказать вызывающему из 3-го он этот тред ресумит. Вроде ниче схемка. Но если она будет еще и применяться для изоляции между слоями API потоки будут расти как на дрожжах. И это только для асинхронных операций. Хотя опять же непонятно остается зачем 19 потоков калькулятору а при нажатии на кнопку равно добавляется еще 5? СОмнительно чтобы он кучу асинхронных операций выполнял в режиме ожидания и 2+2 считал с асинхронным обращением к файлам и тп.

0

Сообщение от Fulcrum_013 А такое количество потоков по всей видимости обусловлено перебором с изоляторами на уровне API. т.е. как изолировать процесс 0-го кольца от процесса 3-его кольца так чтобы осталась возможность отправлять из 0-го кольца в 3-е не только мессаджи но и калбеки?

какое firefox имеет отношение к ring0?

0

Сообщение от cybercitizen какое firefox имеет отношение к ring0?

Прямое. Все данные от и к нему проходят через драйвера живущие в 0-ом кольце. А потоки-изоляторы по всей видимости относятся к вызывающему приложению а не к 0-му кольцу.

0

Fulcrum_013, наличие такой прослойки как операционная система тебя не смущает?

0

Сообщение от Fulcrum_013 Погонять данные туда-сюда от юзера в бд от бд к юзеру? Как раз и есть работа для монкей-кодеров

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

0

Сообщение от cybercitizen наличие такой прослойки как операционная система тебя не смущает?

Нет не смущает. Потому как она собственно говоря и есть набор дров живущих в 0-кольце и API для доступа к их функциям из 3-го кольца.

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

Ну ну. Смотря в каком плане отрывочных. Или кто то с кем это пытаюсь обсуждать до понимания того что с ними обсуждаю просто не дорос.

0

Сообщение от Fulcrum_013 Нет не смущает. Потому как она собственно говоря и есть набор дров живущих в 0-кольце и API для доступа к их функциям из 3-го кольца.

Теперь объясни мне при чем тут лиса.

0

Сообщение от cybercitizen Теперь объясни мне при чем тут лиса.

Объясняю. Лиса хочет загрузить страницу. Обращается к API. т.е. дает адрес и буффер в из которого отправить запрос и буффер в который принять результат. API создает паузнутый поток типа спускового крючка для калбека, и отправляет буфера (вполне возможно соответсвенно преобразованные) и Id потока драйверу. Драйвер после к примеру отправки ресумит поток. Так собственно и происходит асинхронный каллбек, что как бы с изоляцией вызова от 0-го кольца напрямую (имеется в виду не через диспетчерезацию событий вызывающего приложения) по другому не сделать. Но если таких изоляторов еще и между уровнями API натыкать будет не очень хорошая ситуация с ростом количества потоков при наращивании слоев. Это если разработчики выше среднемелкомягкогосертефицированного кодера.

Кстати интересно по какой причине у винды модель потоков cooperative которая очень хороша для тяжелых вычислений на нескольких ядрах заменили на concurency? Учитывая что в разработчиках ядра ОС ни в одной корпорации идиотов не держат ответ прост: те кто не попал в разработчики ядра ОС (ну типа те кто сертификатами курсов майкрософт пообвешался) в основной своей массе и асинхронные операции не осилили.
поэтому вместо оного механизма пользуют синхронный вот по такой схеме:
Естественно при такой схеме начинаются тормоза, особенно если запросов много а конвейер 1 (4 или 8 тоже не сильно помогают). А когда начинает тормозить начинают убирать слипы и повышать приоритет потоков. что вообще ведет к пилюлям от кашля.
То что по дефаулту стек у потока 1MB они тоже успешно не прочитали. Поэтому он по дефаулту и остался. Хорошо хоть винда гарантирует его наличие а не распределяет сразу. Смотрю в монитор ресурсов и обнаруживаю - из 4GB RAM 1.5-2GB - ожидание - т.е этот гарантированный стек спящих непонятно зачем потоков.

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

0

То что ты написал вроде бы и правильно, до конца не читал. Только зачем ты всё это писал? Я не понимаю. Вот твои слова:

Сообщение от Fulcrum_013 А такое количество потоков по всей видимости обусловлено перебором с изоляторами на уровне API. т.е. как изолировать процесс 0-го кольца от процесса 3-его кольца так чтобы осталась возможность отправлять из 0-го кольца в 3-е не только мессаджи но и калбеки?

т.е. здесь ты говоришь о потоках пользовательского приложения и как-то незаметно погружаешься в ядро операционной системы. Но там свои процессы, свои потоки, они не привязаны к процессу в юзерспейсе в том смысле, в котором ты говоришь. Это абстракция. Запросил, подождал, получил. Вызвал epoll_wait и плевать как там оно происходит. Пусть ядро создаст хоть рубль потоков, у лисы сколько было до этого столько и останется. Ты, я смотрю невероятно тугой если говоря о юзерспейсе оказываешься в ring0.

0

Сообщение от cybercitizen Ты, я смотрю невероятно тугой если говоря о юзерспейсе оказываешься в ring0.

Да что ты. Весь ring 0 только и занимается передачей прерываний в ring 3 c изоляцией от устройств и разборам по буферам. Т.е. в принципе что каллбек что обработчик аппаратного прерывания - одно и то же с той лишь разницей что callback получает уже вытянутый из устройства буфер.

Сообщение от cybercitizen Пусть ядро создаст хоть рубль потоков, у лисы сколько было до этого столько и останется.

Ошибаешся. при загрузке страницы у лисы и вообще у всего что пользует драйвер сетки асинхронно, стартует потоков столько сколько запросов она кидает. Эти потоки -курки каллбекаов живут в вызывающем процессе а не в ring 0, ring 0 их только спускает по необходимости.. Именно в вызывающем, для того чтобы имели доступ только к памяти вызывающего процесса.
А вот зачем остальные 70 потоков у ее висят вообще мало понятно.

0

Fulcrum_013, зачем ты пишешь то что не имеет никакого отношения к разговору?

0

Сообщение от cybercitizen Fulcrum_013, зачем ты пишешь то что не имеет никакого отношения к разговору?

К тому чтобы объяснить что если пулы потоков и нужны то уж точно не для асинхронного ввода-вывода. Он как жил на аппаратных прерываниях со времен доски, а вернее со времен появления контроллера прерываний, так и живет.

Добавлено через 1 час 17 минут

Сообщение от cybercitizen Запросил, подождал, получил.

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

Сообщение от cybercitizen Вызвал epoll_wait и плевать как там оно происходит.

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

Добавлено через 23 минуты
Кстати оси с литым ядром (прямая передача управления в код потребителя из обработчика) живут и здравствуют и поныне. Например реалтаймовая QNX.

0

0

Добавлено через 9 часов 0 минут

0