LINUX.ORG.RU

fork() || threads?


0

0

Здравствуйте. Есть приложение, которое должно запускать параллельные процессы для работы. Через что лучше - fork() или потоками? Количество потоков может варьироваться от 5к до 20-30к. Как я понимаю на fork() накладываются отграничения ОС на кол-во процессов, на потоки такое есть? И вообще как быстрее - переключаться между процессами или потоками?

anonymous

Re: fork() || threads?

Переключение между потоками быстрее. Так что лучше их использовыать.

mrco ★★ ()
Ответ на: Re: fork() || threads? от mrco

Re: fork() || threads?

без рута человек так просто не создаст 20к тредов или процессов.

есть большое подозрение на кривизну архитектуры приложения.

а на тему что лучше: треды быстрее а с fork-ами меньше проблем.

возможно автору имеет смысл пользовать их комбинацию

cvv ★★★★★ ()
Ответ на: Re: fork() || threads? от cvv

Re: fork() || threads?

Если не секрет, почему возникло подозрение на кривизну приложения? На основании каких фактов (которых я привел вроде бы совсем немного) возможно сделать такие выводы ?

anonymous ()
Ответ на: Re: fork() || threads? от cvv

Re: fork() || threads?

Возможно стоит использовать что-то в стиле prefork в Apache

Begemoth ★★★★★ ()

Re: fork() || threads?

"Кривизна" заключается в том, что для большого (а > 100 - это много) количества клиентов и усолвно простых сеансов связи можно обойтись одинм потоком и epoll. Или, например, N/50 потоками и poll/select.

-> man

erDiZz ()
Ответ на: Re: fork() || threads? от erDiZz

Re: fork() || threads?

прояодк бкув неажвен, лшиь бы пвреая и псолендяя сотяли на свиох метсах

erDiZz ()

Re: fork() || threads?

> Количество потоков может варьироваться от 5к до 20-30к.

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

Но я бы сделал так, как посоветовал erDiZz (02.09.2005 20:16:57)

Die-Hard ★★★★★ ()

Re: fork() || threads?

Ок, спасибо за совет.

anonymous ()
Ответ на: Re: fork() || threads? от Die-Hard

Re: fork() || threads?

Вдогонку насчет "кривизны"

Если возникает желание на одном (ок, двух, ... 32) процессоре распараллелиться на 10k потоков, это говорит о некоторой кривизне реализации. Именно потакание подобным прихотям привело к интенсивной эксплуатации "MxN" моделей, что IMHO есть зло.

Если _действительно_ сервер способен параллельно обрабатывать запросы 10k клиентов, то это значит, что клиенты не грузят процессор, а просто ждут некоторых событий. Тогда логичнее форкаться не на коннект с клиентом, а на события (или даже сразу создавать пул по числу возможных событий), а клиентов просто ставить в очереди.

Die-Hard ★★★★★ ()
Ответ на: Re: fork() || threads? от Die-Hard

Re: fork() || threads?

Вы совершенно правы, это не числодробильная программа и процессор потоки не грузят никак. Но я не совсем понял фразу "Тогда логичнее форкаться не на коннект с клиентом, а на события (или даже сразу создавать пул по числу возможных событий), а клиентов просто ставить в очереди" ? У каждого процесса СВОИ данные, каждый делает свое дело (есснно одноипное, такое же как все, но данные разные). Или я неправильно понял вашу мысль ?

anonymous ()
Ответ на: Re: fork() || threads? от anonymous

Re: fork() || threads?

Если я правильно его понял, то он говорит, что незачем обрабатывать по 10k клиентов одновременно, достаточно обрабатывать по 100 -- по очереди!

unDEFER ★★★★★ ()
Ответ на: Re: fork() || threads? от unDEFER

Re: fork() || threads?

Ok, спасибо, но все же надо именно одновременно, потому что вычислений на процессоре почти нету. Тогда буду делать потоки

anonymous ()
Ответ на: Re: fork() || threads? от anonymous

Re: fork() || threads?

> потому что вычислений на процессоре почти нету.

Вот именно потому что вычислений нету можно успеть и поочереди обработать!

unDEFER ★★★★★ ()
Ответ на: Re: fork() || threads? от unDEFER

Re: fork() || threads?

Да, я кажется понял что вы имеете ввиду :) Как то сам не додумался, но это намного усложняет реализацию. Спасибо за идею, буду думать :)

anonymous ()
Ответ на: Re: fork() || threads? от unDEFER

Re: fork() || threads?

Прошу прощения, некоторая запарка, сюда лишь урывками заглядываю.

unDEFER (03.09.2005 11:02:13):

> ...незачем обрабатывать по 10k клиентов одновременно, достаточно обрабатывать по 100 -- по очереди!

Немного не то я имел в виду. Не искусственное разбиение на чанки по 100 (кстати, по 100 -- слишком много), а разбиение по группам, ждущим одинаковое "событие".

Я бы сделал так:

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

Тогда я должен вместо "обработчика клиентского запроса" запускать "Обработчик собития", и ставить клиентские запросы в очередь к обработчикам соответствующих событий.

Это касательно логики. На практике обычно делается более извращенно.

Ключевой момент тут таков: если стартовать обновременно 5k нитей, половина из которых могут вдруг одновременно пробудиться, то система будет работать нестабильно, поскольку при одновременном пробуждении большого числа нитей все CPU сожрет шедулер, даже если по памяти не вылетишь.

Из фразы anonymous (*) (03.09.2005 14:20:34):

> все же надо именно одновременно, потому что вычислений на процессоре почти нету.

можно заключить, что все гораздо проще. Скорее всего, надо просто иметь 2 процесса, один коннектится с клиентом и ставит его в FIFO, а второй эту очередь последовательно обрабатывает. С точки зрения клиентских запросов подобная конструкция будет вести себя "одновременнее", чем параллельная обработка в независимых тредах.

Die-Hard ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.