forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Apple выпустила диспетчер потоков Mac OS X под открытой лице..., opennews (??), 12-Сен-09, (0) [смотреть все]

и в чем отличие от posix threads , Vital (??), 02:01 , 12-Сен-09, (1) –2
а у них не было чтоли fork iCreateProcess , ffsdmad (ok), 07:56 , 12-Сен-09, (5) –1
Unix предполагает использование множества процессов для достижения цели, ибо соз, Юниксоид (??), 10:38 , 12-Сен-09, (7) +1 //

потом всё это весело портировать, аноним (?), 11:15 , 12-Сен-09, (8)
К сожалению, не все ещё достигли того уровня мудрости, когда можно наслаждаться , const86 (ok), 11:34 , 12-Сен-09, (10) +2 //

у Apple настолько медленное межпроцессное взаимодействие , Аноним (-), 12:04 , 12-Сен-09, (11) –1 //

Дело не в Apple - в мак оси fork работает Просто используют поэффективнее , letsmac (?), 13:44 , 12-Сен-09, (12) –1

Я далеко не гуру в вопросах многозадачности и т п Поэтому возможно мудрый прог, xxx (??), 13:57 , 12-Сен-09, (13) +1 //

никакая из концепций юникс не отменяет использования многопоточности По теме -, Вова (?), 16:14 , 12-Сен-09, (14) +1
в концепции TBB процессы не нужны И грош цена им Вообще имхо пора бы уже пере, pro100master (ok), 22:44 , 12-Сен-09, (24)
I m the first to admit that I ll probably never be able to create a correct thr, Юниксоид (??), 08:58 , 13-Сен-09, (29) –2 //

Почитай для начала Стивенса, потом напиши пару тестовых серверов, замерь произ, Вова (?), 10:20 , 13-Сен-09, (30)

Некультурный вы наш Если цена fork имеет значение, то ваш сервер либо гифы 1х1 , Юниксоид (??), 19:51 , 13-Сен-09, (33)

говорят, что если цена fork не имеет значения, значит у вашего сервера загрузка , Вова (?), 22:57 , 13-Сен-09, (35)

значит у моего сервера достаточный пул процессов и их балансировка и хватит у, vitek (??), 09:06 , 14-Сен-09, (36)
и ещё забавные ограничения можно подумать, что реализовать нормальный сервер, vitek (??), 09:10 , 14-Сен-09, (37)

В вашем сервере, который существует только в вашем воображении, ассемблерные в, Вова (?), 11:21 , 14-Сен-09, (40) –1

верно но проверенных временем и разработанных лучшими специалистами по всему мир, vitek (??), 19:25 , 14-Сен-09, (43)

Именно форк на каждое соединение клиента - на мое имхо по итогам смотрения как , User294 (ok), 22:12 , 14-Сен-09, (48)

Наверное именно поэтому нагруженные сайты выбрасывают апач в пользу лайта и нжин, User294 (ok), 21:54 , 14-Сен-09, (47)

А потом прикрути машины состояний и пойми что и процессы и треды запускаемые зан, User294 (ok), 22:27 , 14-Сен-09, (49)

это был ответ на реплику о процессах, их преимуществах, о будто бы заточенной п, Вова (?), 14:11 , 15-Сен-09, (59)

Это не всегда возможно, вы про идеальное рассуждаете, как физики про идеальны, Еще один аноним (?), 12:33 , 14-Сен-09, (41)

дизайн GCD позволяет рабочим потокам обмениваться сообщениями не только с родит, anonymous (??), 11:18 , 12-Сен-09, (9) –3
А зачем тогда распараллеливать , pavlinux (ok), 19:32 , 12-Сен-09, (18) –1 //

как иначе ускорять обработку время безумного наращивания частот и усложнения ин, аноним (?), 19:42 , 12-Сен-09, (19) //

Какая разница как добираться до ресурса, через очередь или через очередь очере, pavlinux (ok), 20:12 , 12-Сен-09, (20) –1 //

разве irl не будет иначе A - B - - A o - - A R - - N - - B o , агоним (?), 20:38 , 12-Сен-09, (21)

Выполняются да, без базара Но разговор-то был про очерёдность доступа к блокиру, pavlinux (ok), 04:11 , 13-Сен-09, (28)

Не, просто не все же время работы нитей - это долбежка к одному и тому же ресурс, Еще один аноним (?), 12:44 , 14-Сен-09, (42) //

Естесвенно не всё Но данные например надо кому-нибудь таки отдать, или забрать , letsmac (?), 21:04 , 14-Сен-09, (46) //

МиФи хороший институт, но одно все-таки не понятно так где же отечественные фай, User294 (ok), 22:30 , 14-Сен-09, (50)

В отечественных компах Ну мы же знаем, что за всем стоит user294 который даже , letsmac (?), 22:38 , 14-Сен-09, (51)

Похоже что скоро пингвины будут вынуждены портировать идеи заложенные в этом дис, Erley (ok), 21:20 , 12-Сен-09, (22) +2
Ага Типа я сожру 10 минут на просчитывание нитей, зато сэкономлю тебе 10 секун, kost BebiX (?), 01:45 , 13-Сен-09, (26) –1
Народ не прочитал новость Смысл в получении параллельности для обычной програ, seyko (ok), 03:40 , 13-Сен-09, (27) +1 //

Ну суперскалярность в процах и них есть и без хитрых компиляторов Я так понимаю, tesseract (ok), 10:23 , 13-Сен-09, (31) //

При чем здесь суперскалярность Разного уровня понятия Суть в том, о чем написа, frey (ok), 16:00 , 13-Сен-09, (32) //

при том Вся современная компьютерная тормозня из-за непонятного нежелания инжен, pro100master (ok), 20:52 , 13-Сен-09, (34)

Вы, наверное, плохо отдаёте себе отчёт в том, что здесь совсем недалеко маячит д, pppp (?), 20:08 , 14-Сен-09, (44)

Барьер Это строб в виду имеется Ну даже без Энштейна повторителей никто не от, letsmac (?), 22:46 , 14-Сен-09, (52)
да, да, еще и наводки, материалы с примесями и т д Уже давно это один из первых, pro100master (ok), 22:54 , 14-Сен-09, (53)

Я типо тоже - но это было 10 лет назад И как помню - 133 Мгц вроде как предел д, letsmac (?), 23:05 , 14-Сен-09, (54)

дсл По началу даже сопли не меняли Что до пределов, спутниковые да и мобильники, pro100master (ok), 00:15 , 15-Сен-09, (55)

Угу, только вот у CMOS одна из наиболее энергоэффективных схемотехник известных, User294 (ok), 00:46 , 15-Сен-09, (56)

смотря как охлаждатьреально проложить внутри пластины или криотрубки, аноним (?), 02:24 , 15-Сен-09, (57)

Похрену, помрет от локального перегрева - теплопроводность у полупроводников обы, User294 (ok), 01:15 , 17-Сен-09, (60)

ну вот, опять Интел К ним претензий нет У них и кеш на сравнимой частоте работ, pro100master (ok), 09:15 , 15-Сен-09, (58)

Сообщения [Сортировка по времени | RSS]

7. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..." +1 +/–

Сообщение от Юниксоид (??), 12-Сен-09, 10:38

Unix предполагает использование множества процессов для достижения цели, ибо создание процесса в Unix очень дёшево. Поэтому мудрые программеры в случаях когда возможны описанные side effects юзают процессы, а не потоки.

Ответить | Правка | Наверх | Cообщить модератору

8. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..." +/–

Сообщение от аноним (?), 12-Сен-09, 11:15

>Поэтому муд... программеры в случаях когда возможны описанные
>side effects юзают процессы, а не потоки.
потом всё это весело портировать

Ответить | Правка | Наверх | Cообщить модератору

10. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..." +2 +/–

Сообщение от const86 (ok), 12-Сен-09, 11:34

> мудрые программеры в случаях когда возможны описанные side effects юзают процессы, а не потоки.
К сожалению, не все ещё достигли того уровня мудрости, когда можно наслаждаться простотой и стройностью решения с форком, глядя на потерянную производительность свысока.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

11. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..." –1 +/–

Сообщение от Аноним (-), 12-Сен-09, 12:04

> глядя на потерянную производительность свысока.
у Apple настолько медленное межпроцессное взаимодействие ?

Ответить | Правка | Наверх | Cообщить модератору

12. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..." –1 +/–

Сообщение от letsmac (?), 12-Сен-09, 13:44

Дело не в Apple - в мак оси fork работает. Просто используют поэффективнее.

Ответить | Правка | Наверх | Cообщить модератору

13. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..." +1 +/–

Сообщение от xxx (??), 12-Сен-09, 13:57

Я далеко не гуру в вопросах многозадачности и т. п. Поэтому возможно мудрый программер Юниксоид поведает мне, как указанные side effects (имелось ввиду deadlock и race condition?) само собой обходятся при использовании процессов разделяющих одни ресурсы? Ну и ещё хотелось бы услышать пару аргументов про дешёвое создание процесса, а главное, столь же дешёвое переключение между ними.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

14. "да это просто стёб в лучшем случае" +1 +/–

Сообщение от Вова (?), 12-Сен-09, 16:14

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

Ответить | Правка | Наверх | Cообщить модератору

24. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..." +/–

Сообщение от pro100master (ok), 12-Сен-09, 22:44

>Я далеко не гуру в вопросах многозадачности и т. п. Поэтому возможно мудрый программер >Юниксоид поведает мне, как указанные side effects (имелось ввиду deadlock и race >condition?) само собой обходятся при использовании процессов разделяющих одни ресурсы? Ну >и ещё хотелось бы услышать пару аргументов про дешёвое создание процесса, а главное, столь >же дешёвое переключение между ними.
в концепции TBB процессы не нужны. И грош цена им.
Вообще (имхо) пора бы уже переключать логику людей с процесса на внутренности приложения. В условиях сильной конкуренции, вряд ли какой-то там конь в вакууме может лучше определить, что имели ввиду программисты приложения, и оперативно подсуетиться (опять накладные расходы), чтобы дать таблетку стероида. Тут Интел правильно мыслит.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

29. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..." –2 +/–

Сообщение от Юниксоид (??), 13-Сен-09, 08:58

"I'm the first to admit that I'll probably never be able to create a correct threaded program in C++ or Java, despite years of study. It's just too hard." - Брюс Эккель, ни много ни мало.
deadlock-и при многопроцессном варианте работы реализовать гораздо сложнее, чем в многопоточном. Организовать гонку тоже надо умудриться, я даже не представляю как это осуществить не через ж-пу.
Когда какие-то ресурсы разделяются между процессами - это однозначно плохой дизайн. Процессы между собой должны делить только процессорное время и память, с помощью планировщика и ядра ОС соответственно.
Про дешёвое создание процесса и переключение - архитектура Unix изначально под это заточена.
Обо всём этом отлично описано в книге Эрика С. Реймонда "Искусство программирования для Unix", всем рекоммендую. Если не можете найти, где скачать - выложу.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

30. "ты б написал что-нить" +/–

Сообщение от Вова (?), 13-Сен-09, 10:20

>Обо всём этом отлично описано в книге Эрика С. Реймонда "Искусство программирования
>для Unix", всем рекоммендую. Если не можете найти, где скачать -
>выложу.
  Почитай для начала Стивенса, потом напиши пару тестовых серверов, замерь производительность с потоками и с процессами, потом перди.

Ответить | Правка | Наверх | Cообщить модератору

33. "ты б написал что-нить" +/–

Сообщение от Юниксоид (??), 13-Сен-09, 19:51

Некультурный вы наш !
Если цена fork имеет значение, то ваш сервер либо гифы 1х1 раздаёт, либо hello world в сокет пишет. В таком случае потоки будут заметно быстрее, само собой. Если же рабочий код выполняется продолжительное время, то доля fork будет стремиться к 0.0%
Стивенс в каком месте сказал, что fork это зло ? Ткните, если не сложно.
Пища для размышлений: http://www.radwin.org/michael/blog/2004/01/threads_considere...
Да, писал. И с потоками в том числе. И тоже считаю, что потоки вносят чрезмерную сложность в программу.

Ответить | Правка | Наверх | Cообщить модератору

35. "а у нас на раёне" +/–

Сообщение от Вова (?), 13-Сен-09, 22:57

говорят, что если цена fork не имеет значения, значит у вашего сервера загрузка в два клиента/час (4ре в час пик).
Конкретнее: Стивенс, UNP, глава 23, введение и упр №1.
Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать. Пищу для размышлений можете в факе фидо.ру.юникс.программинг "как писать сервера" черпать, а не в жж бездельников.
Мне пора, рефлексируйте.

Ответить | Правка | Наверх | Cообщить модератору

36. "а у нас на раёне" +/–

Сообщение от vitek (??), 14-Сен-09, 09:06

>если цена fork не имеет значения, значит у вашего сервера загрузка в два клиента/час (4ре в час пик).
значит у моего сервера достаточный пул процессов и их балансировка... и хватит уже.
у потоков есть свои достоинства и недостатки.
допустим никто не скажет, что сервер оракл - хреновый или маленький (или что Вы там приводили?). и опять же подавляющее большинство (да все собстно!) админов скажут, что выделенный оракловый сервер (реализован через процессы) на юникс/линукс НАМНОГО лучше/быстрее/стабильнее, чем разделяемый (реализован через потоки) на винде (а там по другому и нельзя).
не говоря уже о ограничениях, связанных с единым вирт. пространством, ошибками, связанными с общими ресурсами и доступом к ним, а также сложностью с управлением (планировщики ос полюбому лучше и дольше отлажываются и выполняются, чем местечковые разработки или подобные библы... тем более на какой-нибудь другой ОС и/или оборудовании (AMD?... VIA?))
зы:
в результате - действительно нагруженный, сложный и мощьный сервер реализуется через процессы. что не мешает использовать потоки в некоторых, вспомогательных его частях.

Ответить | Правка | Наверх | Cообщить модератору

37. "а у нас на раёне" +/–

Сообщение от vitek (??), 14-Сен-09, 09:10

и ещё:
>Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать.
забавные ограничения!!!
можно подумать, что реализовать "нормальный" сервер можно только на С++!
и ни-ни!!!
а вот стесняюсь спросить, ассемблерные вставки тоже нельзя?

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

40. "Витёк, он же Павлинукс, он же Юсер294" –1 +/–

Сообщение от Вова (?), 14-Сен-09, 11:21

>и ещё:
>>Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать.
>
>забавные ограничения!!!
>можно подумать, что реализовать "нормальный" сервер можно только на С++!
>и ни-ни!!!
>а вот стесняюсь спросить, ассемблерные вставки тоже нельзя?
В "вашем" сервере, который существует только в вашем воображении, ассемблерные вставки не спасут орд от необходимости организации межпроцессного взаимодействия, которое ничуть и ни разу не проще взаимодействия между потоками. Займитесь чем-то полезным, любезный.

Ответить | Правка | Наверх | Cообщить модератору

43. "Витёк, он же Павлинукс, он же Юсер294" +/–

Сообщение от vitek (??), 14-Сен-09, 19:25

верно.
но проверенных временем и разработанных лучшими специалистами по всему миру - навалом.
да и ipc преподаётся во всех учебниках... и диадлоков там точно нет... а если я всё-же (!!!) умудрюсь их накодить, то пользователь сможет всё-равно им управлять (т.к. управляется системой, т.е. ОС - теже утилиты ipcrm, ipcs - набор админа)
зы:
>В "вашем" сервере, который существует только в вашем воображении,
покажите ВАШ сервер... и мы оценим его гениальность.

Ответить | Правка | Наверх | Cообщить модератору

48. "а у нас на раёне" +/–

Сообщение от User294 (ok), 14-Сен-09, 22:12

>говорят, что если цена fork не имеет значения, значит у вашего сервера
>загрузка в два клиента/час (4ре в час пик).
Именно форк на каждое соединение клиента - на мое имхо (по итогам смотрения как это работает на практике и как соотносится с другими варантами) - та еще дурь для многих случаев. Нет, конечно, можно обслужить больше клиентов, впихав машин помощнее и побольше, побольше :).Но почему-то нагруженные сайты в последнее время предпочитают (особенно для статики) серваки на основе машин состояний :).К слову вроде в именно упомянутом факе я видел внятное описание того какие бывают вообще модели построения серверов обслуживающих много клиентов одновременно. Хотя под рукой скорее болтается http://www.kegel.com/c10k.html (у которого тоже рассказано про разные варианты построения серверов).

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

47. "ты б написал что-нить" +/–

Сообщение от User294 (ok), 14-Сен-09, 21:54

> Если цена fork имеет значение, то ваш сервер либо гифы 1х1 раздаёт,
> либо hello world в сокет пишет.
Наверное именно поэтому нагруженные сайты выбрасывают апач в пользу лайта и нжинкса, у которых вместо форков конечные автоматы, которые получаются сильно легче? :)
Тем не менее форк - довольно интересная штука. Все-таки точная копия процесса эффективными методами - это круто и внушает. И позволяет делать ряд вкусностей крайне простыми методами скостив блочащие операции до не-блочащих. Просто данный микроскоп тоже не для любых гвоздей хорошо подходит - иногда молоток типа state machines в серваках оказывается лучше.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

49. "ты б написал что-нить" +/–

Сообщение от User294 (ok), 14-Сен-09, 22:27

>  Почитай для начала Стивенса, потом напиши пару тестовых серверов, замерь
>производительность с потоками и с процессами, потом перди.
А потом прикрути машины состояний и пойми что и процессы и треды запускаемые заново на каждого клиента - форменное зло? :)))

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

59. "ну как бы" +/–

Сообщение от Вова (?), 15-Сен-09, 14:11

это был ответ на реплику о процессах, их преимуществах, о будто бы заточенной под процессы операционной системы.  Если вежливо выразить, то это просто намёк, что у Стивенса можно прочесть главу про многопоточные сетевые приложения, и там  первое упражнение - вот код, сравните производительность на вашей системе.
Принимал участие в разработке двух серверов, на текущем и прошлом месте занятости, использованный шаблон у обоих был один, хоть я и не был автором ни там и не здесь - на каждого клиента нитка, и на всю систему десяток - другой ниток обработки полученных от клиентов данных, клиентские нити живут время существования соединения, обработчики живут время жизни системы. Только что смотрел систему с 500ми клиентами -полёт нормальный, 2-5 %% в top, производительности более чем хватает.  500 процессов тупо бы не влезали в top))

Ответить | Правка | Наверх | Cообщить модератору

41. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..." +/–

Сообщение от Еще один аноним (?), 14-Сен-09, 12:33

> deadlock-и при многопроцессном варианте работы реализовать гораздо сложнее, чем в многопоточном. Организовать гонку тоже надо умудриться, я даже не представляю как это осуществить не через ж-пу.
...
> Когда какие-то ресурсы разделяются между процессами - это однозначно плохой дизайн. Процессы между собой должны делить только процессорное время и память, с помощью планировщика и ядра ОС соответственно.
Это не всегда возможно, вы про идеальное рассуждаете, как физики про идеальный газ или идеальную жидкость. Ресурсы разделяются между процессами довольно часто и это отнюдь не "однозначно плохой дизайн". Несколько процессов (или потоков, в данном случае не важно) зачастую выполняют совершенно разную работу, но при этом в разные моменты своей работы должны взаимодействовать, не только короткими сообщениями. При этом перекачивать друг другу массивы необходимых данных - непроизводительно. Очень наглядный пример - работа серверов БД. Надо по-настоящему одновременно (на многопроцессорных-то системах) обрабатывать несколько запросов от нескольких клиентов. Самое реальное решение - несколько потоков или процессов, выполняющие эту работу (даже не обязательно схема "один запрос-один процесс", можно организовывать очередь запросов к рабочим процессам). Само собой оптимальнее всего кэшировать недавно запрошенную информацию -  держать ее в оперативке. Опять же логично, что каждый процесс не будет держать свой собственный кэш - слишком накладно по памяти и страницы данных, ранее запрошенные одним процессом, могут понадобиться следующему. Следовательно кэш - общая, разделяемая между несколькими процессами область памяти, доступ к которой должен как-то регламентироваться и согласовываться. Это к вопросу о плохом дизайне параллельных систем, использующих общие ресурсы. Вот тут всплывают и понятия примитивов синхронизации - всяких семафоров, мутексов и т.п. А при ошибках программировании  и процессы запросто вогнать в дедлок - процесс A заблокировал семафор №1 и хотел было заблокировать семафор №2. Но процесс B в  этот промежуток времени успел блокировать семафор №2 и потом ему по логике надо было блокировать семафор №1, но он уже блокирован процессом A - вот и клин - каждый процесс до бесконечности ждет освобождения следующего, нужного ему семафора. Процессы и потоки абсолютно равнозначны с точки зрения опасности дедлоков, если они используют общие ресурсы. А отказаться от общих ресурсов зачастую просто невозможно - дело, как говорилось выше, не в плохом дизайне, наверное как раз наоборот - дизайн с отсутствием общих ресурсов в параллельных системах - более редкая ситуация, типа как обработка независимых кусков сцены графической картой или какой-нибудь брутфорс на тысяче компов каждый со своим проверочным диапазоном паролей :)

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

7. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."	+1 +/–
Сообщение от Юниксоид (??), 12-Сен-09, 10:38
Unix предполагает использование множества процессов для достижения цели, ибо создание процесса в Unix очень дёшево. Поэтому мудрые программеры в случаях когда возможны описанные side effects юзают процессы, а не потоки.
Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."	+/–
	Сообщение от аноним (?), 12-Сен-09, 11:15
	>Поэтому муд... программеры в случаях когда возможны описанные >side effects юзают процессы, а не потоки. потом всё это весело портировать
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."	+2 +/–
	Сообщение от const86 (ok), 12-Сен-09, 11:34
	> мудрые программеры в случаях когда возможны описанные side effects юзают процессы, а не потоки. К сожалению, не все ещё достигли того уровня мудрости, когда можно наслаждаться простотой и стройностью решения с форком, глядя на потерянную производительность свысока.
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору


	11. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."	–1 +/–
	Сообщение от Аноним (-), 12-Сен-09, 12:04
	> глядя на потерянную производительность свысока. у Apple настолько медленное межпроцессное взаимодействие ?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."	–1 +/–
	Сообщение от letsmac (?), 12-Сен-09, 13:44
	Дело не в Apple - в мак оси fork работает. Просто используют поэффективнее.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."	+1 +/–
	Сообщение от xxx (??), 12-Сен-09, 13:57
	Я далеко не гуру в вопросах многозадачности и т. п. Поэтому возможно мудрый программер Юниксоид поведает мне, как указанные side effects (имелось ввиду deadlock и race condition?) само собой обходятся при использовании процессов разделяющих одни ресурсы? Ну и ещё хотелось бы услышать пару аргументов про дешёвое создание процесса, а главное, столь же дешёвое переключение между ними.
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору


	14. "да это просто стёб в лучшем случае"	+1 +/–
	Сообщение от Вова (?), 12-Сен-09, 16:14
	никакая из концепций юникс не отменяет использования многопоточности. По теме - интересно, реализованы ли у них посиксовские политики планировки, если да - то как, лучше чем в текущем линуксе или солярисе? Для розжига любопытства добавлю, что сейчас в линуксе довольно коряво с этим, можно свободно блокировать выполнение всех процессов планирующих потоки с незаданной политикой, то есть на данный момент позволяется блокировать/деблокировать работу всех приложений, и это неверно, политики планировки потоков одного процесса не должны влиять на другие.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."	+/–
	Сообщение от pro100master (ok), 12-Сен-09, 22:44
	>Я далеко не гуру в вопросах многозадачности и т. п. Поэтому возможно мудрый программер >Юниксоид поведает мне, как указанные side effects (имелось ввиду deadlock и race >condition?) само собой обходятся при использовании процессов разделяющих одни ресурсы? Ну >и ещё хотелось бы услышать пару аргументов про дешёвое создание процесса, а главное, столь >же дешёвое переключение между ними. в концепции TBB процессы не нужны. И грош цена им. Вообще (имхо) пора бы уже переключать логику людей с процесса на внутренности приложения. В условиях сильной конкуренции, вряд ли какой-то там конь в вакууме может лучше определить, что имели ввиду программисты приложения, и оперативно подсуетиться (опять накладные расходы), чтобы дать таблетку стероида. Тут Интел правильно мыслит.
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	29. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."	–2 +/–
	Сообщение от Юниксоид (??), 13-Сен-09, 08:58
	"I'm the first to admit that I'll probably never be able to create a correct threaded program in C++ or Java, despite years of study. It's just too hard." - Брюс Эккель, ни много ни мало. deadlock-и при многопроцессном варианте работы реализовать гораздо сложнее, чем в многопоточном. Организовать гонку тоже надо умудриться, я даже не представляю как это осуществить не через ж-пу. Когда какие-то ресурсы разделяются между процессами - это однозначно плохой дизайн. Процессы между собой должны делить только процессорное время и память, с помощью планировщика и ядра ОС соответственно. Про дешёвое создание процесса и переключение - архитектура Unix изначально под это заточена. Обо всём этом отлично описано в книге Эрика С. Реймонда "Искусство программирования для Unix", всем рекоммендую. Если не можете найти, где скачать - выложу.
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	30. "ты б написал что-нить"	+/–
	Сообщение от Вова (?), 13-Сен-09, 10:20
	>Обо всём этом отлично описано в книге Эрика С. Реймонда "Искусство программирования >для Unix", всем рекоммендую. Если не можете найти, где скачать - >выложу. Почитай для начала Стивенса, потом напиши пару тестовых серверов, замерь производительность с потоками и с процессами, потом перди.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "ты б написал что-нить"	+/–
	Сообщение от Юниксоид (??), 13-Сен-09, 19:51
	Некультурный вы наш ! Если цена fork имеет значение, то ваш сервер либо гифы 1х1 раздаёт, либо hello world в сокет пишет. В таком случае потоки будут заметно быстрее, само собой. Если же рабочий код выполняется продолжительное время, то доля fork будет стремиться к 0.0% Стивенс в каком месте сказал, что fork это зло ? Ткните, если не сложно. Пища для размышлений: http://www.radwin.org/michael/blog/2004/01/threads_considere... Да, писал. И с потоками в том числе. И тоже считаю, что потоки вносят чрезмерную сложность в программу.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	35. "а у нас на раёне"	+/–
	Сообщение от Вова (?), 13-Сен-09, 22:57
	говорят, что если цена fork не имеет значения, значит у вашего сервера загрузка в два клиента/час (4ре в час пик). Конкретнее: Стивенс, UNP, глава 23, введение и упр №1. Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать. Пищу для размышлений можете в факе фидо.ру.юникс.программинг "как писать сервера" черпать, а не в жж бездельников. Мне пора, рефлексируйте.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	36. "а у нас на раёне"	+/–
	Сообщение от vitek (??), 14-Сен-09, 09:06
	>если цена fork не имеет значения, значит у вашего сервера загрузка в два клиента/час (4ре в час пик). значит у моего сервера достаточный пул процессов и их балансировка... и хватит уже. у потоков есть свои достоинства и недостатки. допустим никто не скажет, что сервер оракл - хреновый или маленький (или что Вы там приводили?). и опять же подавляющее большинство (да все собстно!) админов скажут, что выделенный оракловый сервер (реализован через процессы) на юникс/линукс НАМНОГО лучше/быстрее/стабильнее, чем разделяемый (реализован через потоки) на винде (а там по другому и нельзя). не говоря уже о ограничениях, связанных с единым вирт. пространством, ошибками, связанными с общими ресурсами и доступом к ним, а также сложностью с управлением (планировщики ос полюбому лучше и дольше отлажываются и выполняются, чем местечковые разработки или подобные библы... тем более на какой-нибудь другой ОС и/или оборудовании (AMD?... VIA?)) зы: в результате - действительно нагруженный, сложный и мощьный сервер реализуется через процессы. что не мешает использовать потоки в некоторых, вспомогательных его частях.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "а у нас на раёне"	+/–
	Сообщение от vitek (??), 14-Сен-09, 09:10
	и ещё: >Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать. забавные ограничения!!! можно подумать, что реализовать "нормальный" сервер можно только на С++! и ни-ни!!! а вот стесняюсь спросить, ассемблерные вставки тоже нельзя?
	Ответить \| Правка \| К родителю #35 \| Наверх \| Cообщить модератору


	40. "Витёк, он же Павлинукс, он же Юсер294"	–1 +/–
	Сообщение от Вова (?), 14-Сен-09, 11:21
	>и ещё: >>Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать. > >забавные ограничения!!! >можно подумать, что реализовать "нормальный" сервер можно только на С++! >и ни-ни!!! >а вот стесняюсь спросить, ассемблерные вставки тоже нельзя? В "вашем" сервере, который существует только в вашем воображении, ассемблерные вставки не спасут орд от необходимости организации межпроцессного взаимодействия, которое ничуть и ни разу не проще взаимодействия между потоками. Займитесь чем-то полезным, любезный.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Витёк, он же Павлинукс, он же Юсер294"	+/–
	Сообщение от vitek (??), 14-Сен-09, 19:25
	верно. но проверенных временем и разработанных лучшими специалистами по всему миру - навалом. да и ipc преподаётся во всех учебниках... и диадлоков там точно нет... а если я всё-же (!!!) умудрюсь их накодить, то пользователь сможет всё-равно им управлять (т.к. управляется системой, т.е. ОС - теже утилиты ipcrm, ipcs - набор админа) зы: >В "вашем" сервере, который существует только в вашем воображении, покажите ВАШ сервер... и мы оценим его гениальность.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "а у нас на раёне"	+/–
	Сообщение от User294 (ok), 14-Сен-09, 22:12
	>говорят, что если цена fork не имеет значения, значит у вашего сервера >загрузка в два клиента/час (4ре в час пик). Именно форк на каждое соединение клиента - на мое имхо (по итогам смотрения как это работает на практике и как соотносится с другими варантами) - та еще дурь для многих случаев. Нет, конечно, можно обслужить больше клиентов, впихав машин помощнее и побольше, побольше :).Но почему-то нагруженные сайты в последнее время предпочитают (особенно для статики) серваки на основе машин состояний :).К слову вроде в именно упомянутом факе я видел внятное описание того какие бывают вообще модели построения серверов обслуживающих много клиентов одновременно. Хотя под рукой скорее болтается http://www.kegel.com/c10k.html (у которого тоже рассказано про разные варианты построения серверов).
	Ответить \| Правка \| К родителю #35 \| Наверх \| Cообщить модератору


	47. "ты б написал что-нить"	+/–
	Сообщение от User294 (ok), 14-Сен-09, 21:54
	> Если цена fork имеет значение, то ваш сервер либо гифы 1х1 раздаёт, > либо hello world в сокет пишет. Наверное именно поэтому нагруженные сайты выбрасывают апач в пользу лайта и нжинкса, у которых вместо форков конечные автоматы, которые получаются сильно легче? :) Тем не менее форк - довольно интересная штука. Все-таки точная копия процесса эффективными методами - это круто и внушает. И позволяет делать ряд вкусностей крайне простыми методами скостив блочащие операции до не-блочащих. Просто данный микроскоп тоже не для любых гвоздей хорошо подходит - иногда молоток типа state machines в серваках оказывается лучше.
	Ответить \| Правка \| К родителю #33 \| Наверх \| Cообщить модератору


	49. "ты б написал что-нить"	+/–
	Сообщение от User294 (ok), 14-Сен-09, 22:27
	> Почитай для начала Стивенса, потом напиши пару тестовых серверов, замерь >производительность с потоками и с процессами, потом перди. А потом прикрути машины состояний и пойми что и процессы и треды запускаемые заново на каждого клиента - форменное зло? :)))
	Ответить \| Правка \| К родителю #30 \| Наверх \| Cообщить модератору


	59. "ну как бы"	+/–
	Сообщение от Вова (?), 15-Сен-09, 14:11
	это был ответ на реплику о процессах, их преимуществах, о будто бы заточенной под процессы операционной системы. Если вежливо выразить, то это просто намёк, что у Стивенса можно прочесть главу про многопоточные сетевые приложения, и там первое упражнение - вот код, сравните производительность на вашей системе. Принимал участие в разработке двух серверов, на текущем и прошлом месте занятости, использованный шаблон у обоих был один, хоть я и не был автором ни там и не здесь - на каждого клиента нитка, и на всю систему десяток - другой ниток обработки полученных от клиентов данных, клиентские нити живут время существования соединения, обработчики живут время жизни системы. Только что смотрел систему с 500ми клиентами -полёт нормальный, 2-5 %% в top, производительности более чем хватает. 500 процессов тупо бы не влезали в top))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."	+/–
	Сообщение от Еще один аноним (?), 14-Сен-09, 12:33
	> deadlock-и при многопроцессном варианте работы реализовать гораздо сложнее, чем в многопоточном. Организовать гонку тоже надо умудриться, я даже не представляю как это осуществить не через ж-пу. ... > Когда какие-то ресурсы разделяются между процессами - это однозначно плохой дизайн. Процессы между собой должны делить только процессорное время и память, с помощью планировщика и ядра ОС соответственно. Это не всегда возможно, вы про идеальное рассуждаете, как физики про идеальный газ или идеальную жидкость. Ресурсы разделяются между процессами довольно часто и это отнюдь не "однозначно плохой дизайн". Несколько процессов (или потоков, в данном случае не важно) зачастую выполняют совершенно разную работу, но при этом в разные моменты своей работы должны взаимодействовать, не только короткими сообщениями. При этом перекачивать друг другу массивы необходимых данных - непроизводительно. Очень наглядный пример - работа серверов БД. Надо по-настоящему одновременно (на многопроцессорных-то системах) обрабатывать несколько запросов от нескольких клиентов. Самое реальное решение - несколько потоков или процессов, выполняющие эту работу (даже не обязательно схема "один запрос-один процесс", можно организовывать очередь запросов к рабочим процессам). Само собой оптимальнее всего кэшировать недавно запрошенную информацию - держать ее в оперативке. Опять же логично, что каждый процесс не будет держать свой собственный кэш - слишком накладно по памяти и страницы данных, ранее запрошенные одним процессом, могут понадобиться следующему. Следовательно кэш - общая, разделяемая между несколькими процессами область памяти, доступ к которой должен как-то регламентироваться и согласовываться. Это к вопросу о плохом дизайне параллельных систем, использующих общие ресурсы. Вот тут всплывают и понятия примитивов синхронизации - всяких семафоров, мутексов и т.п. А при ошибках программировании и процессы запросто вогнать в дедлок - процесс A заблокировал семафор №1 и хотел было заблокировать семафор №2. Но процесс B в этот промежуток времени успел блокировать семафор №2 и потом ему по логике надо было блокировать семафор №1, но он уже блокирован процессом A - вот и клин - каждый процесс до бесконечности ждет освобождения следующего, нужного ему семафора. Процессы и потоки абсолютно равнозначны с точки зрения опасности дедлоков, если они используют общие ресурсы. А отказаться от общих ресурсов зачастую просто невозможно - дело, как говорилось выше, не в плохом дизайне, наверное как раз наоборот - дизайн с отсутствием общих ресурсов в параллельных системах - более редкая ситуация, типа как обработка независимых кусков сцены графической картой или какой-нибудь брутфорс на тысяче компов каждый со своим проверочным диапазоном паролей :)
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору