Можно ли так сделать :

хешь с данными обьявляем как our
создаём потоки (fork)
из каждого потока работаем с хешем (не изменяем его)

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

Подскажите, вопрос очень важный.

fork потоки не создаёт; в виндусовом может создавать - но вообще говоря fork это не потоки а копии процесса со своей версией данных.

http://search.cpan.org/~jdhedden/threads-s...-1.32/shared.pm

Соответственно задам избитый (наверное) вопрос: каким способом экономичнее, с точки зрения расходования оперативной памяти, реализовывать многопоточность в Perl.

1. fork
2. use threads;

спасибо.

где(ОС)?

*nix like ОС

Один хрен много будет. 

mvsgt а что посоветуешь, как дешевле всего выполнять параллельно несколько потоков ?

А о каком вообще количестве потоков речь?

50-100

ну это относительно, сейчас машина с 1гб озу, есле будет больше озу то и потоков следовательно надо больше ....

Это сообщение отредактировал(а) nIkTo - 12.11.2009, 01:39

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

А вот потоки в каком-нибудь curl гораздо легче, на порядки.

К примеру запускаю тестовый скрипт :



Вот что показывает htop :


я так понимаю что скрипт расходует (включая все потоки) 3,6% памяти, тоесть ~ 36 Мб, значит ~ 0,36 Мб на поток

Может и дурацкий вопрос, но за что отвечает 'stack_size' ?

Понятно что это размер стека, но вот какой конкретно размер нужен(желателен) ? как его определить ?

Это сообщение отредактировал(а) nIkTo - 12.11.2009, 02:07

fork - если быть предельно корректным - ветвление, а многопоточность это немного иное. И разница в функциональных возможностях у них разная.  И тут все зависит от выбора верного инструмента для решения задачи. А так может и то и другое

Bulat, можешь на примерах задачь показать, для задачь какого типа стоит использовать fork, а для каких threads ? И по какому критерию надо определять каким "инструментом" работать?
Иначе ваши слова пустой звук не раскрывающий суть вопроса, так как если быть предельно корректным, то я и до вашего комента понимал что fork это ветвление которое создаёт точную копию процесса, причём новый процесс имеет свою собственную область памяти, так же я догадывался что  :

и так же догадывался что :

так же знал :

знал и то, что можно юзать fork и threads :

threads - потребляют меньше памяти. Но технология принципиально нестабильная
forks - потребляют больше памяти, хотя если вы активно ее не меняете ОС все равно попытается ее расшарить (за счет copy - on -write старниц)

а еще есть (!) event-driven программирование. Да, это боян, но я еще раз предложу:

use POE;

use AnyEvent;

В этом случае у вас всего один процесс. По грузит ядро процессора по максимуму. Т.е. не ждет ввода-вывода.  По хорошему нужно создать несколько процессов по количеству ядер и каждый из них должен работать на POE или AnyEvent.

POE, что за зверь такой?
где читнуть про него ?

в библиотеке
Про AnyEvent там же.  Думаю что вам лучше будет про него почитать - он попроще.

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

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

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

У fork и thread принципиальное отличие в способах общения между собой потоков и процессов, для потоков гораздо проще. Но некоторые модули перла, например DBI, с потоками могут глючить. Если надо обращаться к общей памяти - то надо выбирать потоки, если это приложение, которое может внезапно рухнуть - лучше процессы.

Я бы отметил, что это относится только к перлу. И еще на *nix подобных ОС они работают, как оказалось, получше, чем на Windows.


А я так и не померил все сам. Есть ссылочка на готовые замеры?

Да, речь только о perl. 
На windows - при запуске ~ 30 потоков я получал креш в 50 % случаев. Печально

Очень любопытно было-бы посметреть на такие замеры, у меня как не проведу замеры каждый раз fork меньше памяти потребляет =)

Проблема перла в том, что в нём нет потоков. Забудьте о threads. Это полноценные процессы, создание которых занимает значительное время, и потребляет памяти больше, чем fork  в *nix cистемах (в windows - одинаково). Нет нормальной разделяемой памяти (threads::shared - это чёрная магия, никакой разделяемой памяти). 

Если ваша задача упирается в cpu - используйте fork. Сначала загрузить все модули и данные в память, а потом форкаться. Память будет дублироваться только для изменённых данных. Если упирается в ожидание ввода/вывода - я бы посоветовал Coro. Или AnyEvent::EV. Или IO::Lambda. Но не POE ;)

Это сообщение отредактировал(а) DurRandir - 15.11.2009, 16:22

Достаточно посмотреть в исходники, чтобы убедиться, что вы не правы.

Товарищ не так уж далек от истины.. В том плане, что в перле на каждый поток создается свой интерпретатор, с полной копией данных. 
А уж потом некоторые данные делаются общими (с помощью shared переменных).
Так что выигрыш в памяти может быть незаметным.

OC скопирует нужные (и только нужные, и только при необходимости) страницы данных в новом процессе быстрее и эффективнее, чем копирование вручную всего интерпретатора заранее, пусть даже и внутри одного процесса. Перловые threads потоки в том смысле, что они используют общее адресное пространство (добавляя много весёлого при работе с XS модулями). Но они не потоки в том смысле, который обычно подразумевается - достаточно дешёвый объект, использующий полностью разделяемую память при обращении к данным и имеющий выделенный стек. Перловые потоки - это бекпорт на *nix програмной эмуляции fork на win-системах.

PS: да, ещё один модуль вспомнил - forks.

Это сообщение отредактировал(а) DurRandir - 16.11.2009, 14:48

Я в курсе. Читал сорцы наискосок. Тем не менее, в ОС в которых доступна библиотека pthread будут нормальные потоки (если конечно специально не отключить эту возможность при сборке). Да, с интерпретатором внутри. Но потоки.

Немного отсутпая от темы: если вас волнует скорость и обилие системных вызовов, устройство потоков и подобные вещи, то пора переходить на Си.

Добавлено @ 14:58

Два раза прочитал, но не уверен, что понял правильно. Да, в windows потоки эмулируются через fork, который тоже в свою очередь эмулируется через что-то. Это имелось в виду?

Это сообщение отредактировал(а) KSURi - 16.11.2009, 14:58

Потоки в *nix используют код, похожий на тот, что используется в win для эмуляции fork (там он эмулируется как-раз через виндовые потоки).


Меня волнует бесцельное разбазаривание ресурсов  У меня есть форкающийся демон, при соотношение vss/rss 75mb/35mb реальный расход памяти на 1 экземпляр - 10мб. А с потоками было бы под 25-30 (я не уверен, сколько именно займёт клон интерпретатора).

Потоки в *nix используют POSIX threads (ака pthreads) по умолчанию, а в win* - функции предоставляемые ядром ОС (CreateThread) (не уверен на 100%, подсказали). В каком смысле они "похожи"?
Таким образом, по крайней мере на nix* ОС мы имеем полноценные потоки, пусть они и жрут память.


Откуда информация? Она перекрывает одно из преимуществ потоков - легковесность по сравнению с процессами.

Это стандартный механизм Copy-on-Write. Точно применяется при форке в Linux & Freebsd.

Почему быстрее? Потому что этим сразу занимается ОС. 
Почему эффективнее? Потому что копируется только то, что меняется (название метода). А клонирование интерпретатора - это копирование всей памяти заранее, не зная, надо это или нет. А с форком приложению ни о чём не надо беспокоиться.


Что делаем в win для эмуляции форка? 
1. Нам надо создать копию приложения - создаём новый поток
2. Но все данные (пока) общие, поэтому клонируемся, делая все данные приватными
3. Мы получили поток, но с изолированной памятью - по сути, процесс, что и требовалось

Теперь в nix:
1. Нам надо создать поток - создаём его
2. Клонируемся, делая все данные приватными, не трогая ::shared (или тоже клонируем, но не суть)
3. Получили перловый поток. Но чем он отличается от win-"процесса"?

А теперь по легковесности - я даже тредовый перл собрал на тестовой машинке 

use <many modules>;
for (1..2000){
  if (fork){
    next;
  }else{
    exit 0;
  }
}
runtime: 11.7451310157776

А теперь

for (1..2000){
  threads->create(sub{
    return 1;
  })->detach();
}

Out of memory! Сам скрипт занимает ~10мб в памяти. Убираем немного модулей...segmentation fault! Добро пожаловать в мир несовместимостей) Оставляю только Time::HiRes.
runtime: 13.0303740501404

А если ждать завершения каждого потока? Меняем detach->join
runtime: 9.81970191001892

Ну и чтобы убедиться, что потоки съедают память на ура - добавляем и для потоков, и для процессов sleep 5.

Created thread #883
Thread creation failed: pthread_create returned 35 at ./threads.pl line 33.

Упираемся в ограничение 512res для процесса.

Для процессов: Mem: 730M Active по сравнению с Mem: 559M Active в обычном состоянии. Дельта - 171мб. На все 2000 процессов.