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

[Blabos de Blebe]

P.S.: Não ponha Java. Seria chamar a Death Star para matar um vírus.

2010/7/10 Blabos de Blebe <blabos em gmail.com>:
> 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
>>
>