_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
From : Vladimir A. Butenko 2:5020/400 05 Dec 99 02:21:04
Subj : Re: pthreads on Cobalt RaQ
________________________________________________________________________________
From: butenko@stalker.com (Vladimir A. Butenko)
In article <82bfi6$crn$1@alx.private>, Alex Korchmar
<Alex.Korchmar@p65.f423.n5020.z2.fidonet.org> wrote:
> >> нормально работали только митовские). А до того единственный юникс с
> >> тредами был - соляра.
>
> VAB> Hет. D/Unix. IRIX. То есть - почти все. (HPUX and AIX - попозже). Всякие
> мне показалось, или "попозже" получилось - позже, чем у фрюниксов.
У "фрюниксов" оно только в Linux-е работает, да и то порою - "странновато".
> >> P.S. причем двухпроцессорных кобальтов не бывает в принципе.
>
> VAB> Какая связь меж многопроцессорностью и малтитредовостью?! Hу и
> малтитредовая задача на SMP-машине - позволяет распределить нагрузку на
> халяву. Hа однопроцессорной - попусту грузит планировщик.
> Hу и нафига?
> Или вы хотите сказать, что возиться с синхронизацией этих тредов - проще,
> чем пресловутый конечный автомат нарисовать? Про отладку лучше уж вообще
> не заикаться.
а) про отладку многопроцессных систем (на чем Вы их делаете - на процессах
или тредах или отдельных машинах - не важно) - про это отладку заикаться
не надо только тогда, когда у Вас HЕТУ многопроцессных задач (а это вряд
ли). А если он у Вас есть, но взаимодействие меж ними примитивное
(stdin-stdout) - ну так отладка просто проще - но она все равно есть. Беда
(и не беда) в том, что взаимодействие между процессами отнюдь не всегда
сводится к примитивному унихному "filtering", под который был заточен Уних
25 лет назад.
б) по сравнению с многопроцессными системами многотредовые предоставляют:
1. значительно больший набор методов взаимодействия
2. значительно большую скорость этого взаимодействия.
Обе причины позволяют на малтитредовых системах реализовывать то, что
на многопроцессных системах ТОЖЕ возможно, но получается настолько
уродливо и медленно, что никто этим (почти) не занимается.
Основная разница между мнопроцессными и многотредовыми реализациями -
доступ к общей памяти. Если у Вас многопроцессный комплекс вынужден
использовать общую память, полученную через ОС, или эмулировать ее на
общем файле - то это та же многотредовая система, просто сделанная через
задницу.
Задач - кучи. Любой сервер, выдающий общие (точнее, сильно-общие) данные -
в принципе своем много-тредовая задача. Тот же DNS-сервер, например,
который имеет общие данные - таблицу кэша с DNS-записями и кучу запросов,
приходящих от разных клиентов и требующих различной работы (включая
модификацию) этой самой общей памяти.
То, что такой сервер можно сделать и на куче процессов и на конечном
автомате - бесспорно. Сама задача от этого не меняется - это будет
малтитредовая по сути задача, реализованная через другие механизмы.
Этими другими механизмами пользуются по трем причинам:
а) задача слишком проста, и взаимодействие мало или просто;
б) задача достаточно сложна, но настоящего механизма малтитрединга в
системе нету.
в) задача достаточно сложна, механизм малтитрединга в системе есть, но
писатель программы не умеет им пользоваться, потому как в книжках, которые
он читал 10 лет назад, работа в малтитредовой среде была не описана.
> > Alex
--
Vladimir Butenko
Stalker Software, Inc.
--- ifmail v.2.14dev3 * Origin: Stalker Software, Inc. (2:5020/400)
