[Rio-pm] Ajuda com Threads - tempo de abertura

[Blabos de Blebe]

João, por que tanto loop aninhado?

Eu gostara que você comentasse o porquê de cada coisa. Não se ofenda,
o código tá uma bagunça, misturando declaração de função com main
thread.

ithreads usam por debaixo dos panos pthreads, com a diferença que a
api em Perl é de longe muito mais mamão com acúcar do que a API em C.

Não fui ao código fonte dos módulos, mas suponho que a criação de
threads em Perl seja tão custoso quanto em C. A partir do kernel 2.6.x
isso tornou-se irrelevante (falando em C).

Existe uma lenda urbana de que criar threads é lento. Essa frase dita
ao vento, é besteira. Meu código de exemplo mostra como criar 300
threads em um eeePc em menos de um seg.

Eu só quero me certificar que o que você está querendo fazer esteja
conceitualmente coerente, antes de te mandar soluções mirabolantes.

Lidando com threads, tudo precisa estar conceitualmente correto.
Testes não funcionam bem neste caso por conta do não-determinismo.

Eu preciso que você me ajude a entender 'what you means' ao invés de
'what you say'. Seu problema deve estar carregado de peculiaridades
que não ficaram claras no código.

Abraços

2010/7/10 Bruno Buss <bruno.buss em gmail.com>:
> Olá Blabos,
>
> 2010/7/10 Blabos de Blebe <blabos em gmail.com>
>>
>> Desculpe a minha ignorância e o meu estado sonolerdo, mas por que vc
>> faz join dentro do loop que cria a thread?
>>
>> Eu posso ter entendido errado, mas se for isso vc não está
>> serializando as threads?
>
> Também não tenho certeza (afinal o código não é meu :P), mas acho que o que
> ele faz naquele loop interno é se o número de threads existentes for maior
> que o limite dele (250 no caso), ele entre no loop e faz join em uma das
> threads, para esperar que ela possa acabar e disparar uma nova thread.
> Além disso, como ele faz o segundo loop interno baseado no retorno da
> listagem de "threads::joinable", que são threads que já acabaram seu
> processamento e estão apenas esperando para serem finalizadas e puxar o
> resultado delas de volta, então as operações de join() ai são não
> bloqueantes.
>
> Apenas frisando, minha experiência real em aplicações paralelas é baixa,
> então se eu disser alguma besteira grande por favor me avisem/corrijam.
>
> João, será que utilizando algo como Thread::Pool[1] ou
> Thread::Pool::Simple[2] seu código não ficaria mais organizado?
> Segundo o perldoc perlthrtut[3]:
> "Performance considerations
>        The main thing to bear in mind when comparing Perl's ithreads to
> other threading models is the fact that for each new thread created, a
> complete copy of all the variables
>        and data of the parent thread has to be taken. Thus, thread creation
> can be quite expensive, both in terms of memory usage and time spent in
> creation. The ideal way to
>        reduce these costs is to have a relatively short number of long-lived
> threads, all created fairly early on -- before the base thread has
> accumulated too much data. Of
>        course, this may not always be possible, so compromises have to be
> made. However, after a thread has been created, its performance and extra
> memory usage should be little
>        different than ordinary code."
> Principalmente a parte do: "Thus, thread creation can be quite expensive,
> both in terms of memory usage and time spent in creation.".
> Será que aqui uma implementação utilizando uma pool de threads (como
> sugerido acima), não seria melhor? :)
> (ps: eu não sei o quanto atualizado está essa documentação, mas ela está
> presente no perldoc do perl 5.12.1)
>
> [1] http://search.cpan.org/~elizabeth/Thread-Pool-0.32/lib/Thread/Pool.pm
> [2] http://search.cpan.org/~jwu/Thread-Pool-Simple-0.24/Simple.pm
> [3] http://perldoc.perl.org/perlthrtut.html
>
> [ ]'s
> --
> Bruno C. Buss
> http://brunobuss.wordpress.com/
> http://www.dcc.ufrj.br/~brunobuss/
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>