[Rio-pm] Multi threads
Tiago Peczenyj
tiago.peczenyj em gmail.com
Segunda Março 12 13:36:31 PDT 2012
Ola
Entre threads, forks e eventos até hoje eu não tenho muita experiência em
Perl. Eu lembro que threads possuem alguns problemas devido ao Global
Interpreter Lock. Agora eu consigo utilizar mais de um core de CPU com um
processo perl?
Eu tenho a tendência de pensar em Eventos, mesmo sabendo que não são para o
mesmo propósito.
Att
Tiago
On Mon, Mar 12, 2012 at 10:13 AM, Stanislaw Pusep <creaktive em gmail.com>wrote:
> Mas será que depende tanto assim de CPU? ;)
> Veja essa tabela (aliás, o artigo em si é excelente):
> http://norvig.com/21-days.html#answers
> Daí deduzimos que, desprezando todo o tipo de atrito, enquanto *UM* pacote
> ICMP está a caminho, uma CPU mequetrefe executará *150 MILHÕES* de
> instruções. Todavia, o que eu tenho certeza absoluta é que o overhead de
> gerenciar processos/threads "paralelos" tenderá a ocupar a CPU inteiramente
> :(
> Todavia, não há a menor necessidade de gerenciar processos/threads, ao
> menos, nesse caso! Muitas pessoas empregam threads apenas para contornar o
> "blocking" das operações de I/O. Outra forma é simplesmente... desabilitar
> o "blocking".
>
> ABS()
>
>
>
>
> On Mon, Mar 12, 2012 at 09:54, Aureliano Guedes <guedes_1000 em hotmail.com>wrote:
>
>> Hoje em dia os moldens mais simples pode bloquear ping por defaut,
>> contudo no trecho citado vc falou de 2GHz.
>>
>> Testa um i7 e usando GPU com uma placa de video poderosa, levando uma
>> internet de 15MB/s (a minha é so 10MB/p).
>>
>> Facilitaria bastante, não?
>>
>> No meu caso, como sou programador por esporte, e me interesso pela parte
>> de segurança digital, quero aprender intimamente
>> a parte "underground", para isso tenho uma rede configurada onde um
>> Windows 95 esta me esperando pra brincar com ele.
>> ------------------------------
>> From: creaktive em gmail.com
>> Date: Mon, 12 Mar 2012 09:42:52 -0300
>>
>> To: rio-pm em pm.org
>> Subject: Re: [Rio-pm] Multi threads
>>
>> Da documentação do AnyEvent::FastPing:
>>
>> "Performance: On my 2 GHz Opteron system with a pretty average nvidia
>> gigabit network card I can ping around 60k to 200k addresses per second,
>> depending on routing decisions"
>>
>> Tentar isso com threads certamente vai derrubar o host... O SEU :P
>>
>> ABS()
>>
>>
>>
>> On Mon, Mar 12, 2012 at 09:01, Vinícius Miasato <
>> viniciusmiasato em gmail.com> wrote:
>>
>> >Ainda dá pra derrubar servidor com ping hoje
>> > em dia?
>>
>> dependendo do servidor, sim, mas creio que são raridades hoje em dia,
>>
>> >Tem uma coisa que a maioria ignora sobre threads, que é o fato de elas
>> >serem utilizadas para rodar código em paralelo quando o processador
>> >está *ocioso*.
>>
>> não necessariamente. não se usa threads para rodar código somente pelo
>> processador estar ocioso. threads geralmente são utilizadas para
>> executar tarefas distintas pois quando uma thread entrar em um estado
>> bloqueante, as demais ainda podem entrar em execução, porém isso
>> também não é regra.
>>
>> > Fique esperto também com a afinidade. Não necessariamente quatro
>> > threads rodando em um processador com quatro núcleos vão rodar cada
>> > uma em um núcleo. Eventualmente, você pode criar N threads que rodem
>> > em apenas um dos núcleos, e aí você se lascou.
>>
>> com uma boa programação e se o SO permitir, você pode escolher em qual
>> núcleo cada processo executa =D
>>
>> abs.
>> Japa
>>
>> Em 12 de março de 2012 00:38, Blabos de Blebe <blabos em gmail.com>
>> escreveu:
>> >> Bem, agora exclareceu mais o assunto na minha cabeça, contudo me
>> deixou com
>> >> mais medo de usar threads... hahaha.
>> >
>> > Se você tem medo de usar threads, então você não está pronto pra usar
>> threads.
>> >
>> >> Bem, esquecendo o assunto de redes, o que eu pretendo fazer é pingar um
>> >> servidor, contudo inves de usar 4 bot para
>> >> enviar 4 pings simultaneos eu quero usar uma unica maquina para enviar
>> esses
>> >> 4 pings. Mas é so uma questão de estudo
>> >> nada de underground.
>> >
>> > Estudo, sei...
>> >
>> > Bem, uma rede bem configurada vai solenemente cagar pro seus pings,
>> > então vou supor que você está estudando como configurar redes de forma
>> > a evitar um DoD por ping. Ainda dá pra derrubar servidor com ping hoje
>> > em dia?
>> >
>> >> Exemplos que achei na internet não davam muita mobilidade de escolher o
>> >> numero de threads e tals.
>> >
>> > Exemplos de threads que você (você, um sujeito genérico, ok)
>> > normalmente são porcaria. O que você precisa é ler com atenção o livro
>> > de SO do tio Tanenbaum http://www.pearsonhighered.com/tanenbaum.
>> >
>> > ...
>> >
>> > Tem uma coisa que a maioria ignora sobre threads, que é o fato de elas
>> > serem utilizadas para rodar código em paralelo quando o processador
>> > está *ocioso*.
>> >
>> > Lembre-se sempre que há um custo para o SO fazer a troca de contexto e
>> > se o seu código for CPU bound, fazer o processador ficar chaveando
>> > contexto quando ele deveria estar processando, é perda de tempo.
>> >
>> > Threads são melhores utilizadas para executar tarefas enquanto alguma
>> > parte do código está esperando I/O. Por exemplo, interface gráfica,
>> > que fica fica esperando o usuário interagir, ou ainda código que faz
>> > I/O, como o seu caso.
>> >
>> > Fique esperto também com a afinidade. Não necessariamente quatro
>> > threads rodando em um processador com quatro núcleos vão rodar cada
>> > uma em um núcleo. Eventualmente, você pode criar N threads que rodem
>> > em apenas um dos núcleos, e aí você se lascou.
>> >
>> >
>> > []'s
>> >
>> >
>> >
>> >
>> >
>> > 2012/3/11 Aureliano Guedes <guedes_1000 em hotmail.com>:
>> >> Bem, agora exclareceu mais o assunto na minha cabeça, contudo me
>> deixou com
>> >> mais medo de usar threads... hahaha.
>> >>
>> >> Bem, esquecendo o assunto de redes, o que eu pretendo fazer é pingar um
>> >> servidor, contudo inves de usar 4 bot para
>> >> enviar 4 pings simultaneos eu quero usar uma unica maquina para enviar
>> esses
>> >> 4 pings. Mas é so uma questão de estudo
>> >> nada de underground.
>> >>
>> >> Exemplos que achei na internet não davam muita mobilidade de escolher o
>> >> numero de threads e tals.
>> >>
>> >> Mas valeu, monges, me ajudou muito mesmo.
>> >>
>> >>> Date: Sun, 11 Mar 2012 22:58:20 -0300
>> >>> From: viniciusmiasato em gmail.com
>> >>
>> >>> To: rio-pm em pm.org
>> >>> Subject: Re: [Rio-pm] Multi threads
>> >>>
>> >>> só para não ficar confuso demais, a variável $pool_thr[ $i ] não
>> >>> recebe o retorno das threads. ela serve como uma forma de controle das
>> >>> threads, para efetuar join, detach ou executar outros métodos
>> >>> fornecidos,
>> >>>
>> >>> o link para a documentação mais detalhada estpa abaixo:
>> >>> http://perldoc.perl.org/threads.html
>> >>>
>> >>> abs.
>> >>> Japa
>> >>>
>> >>> Em 11 de março de 2012 22:53, Vinícius Miasato
>> >>> <viniciusmiasato em gmail.com> escreveu:
>> >>> > olá Aureliano,
>> >>> >
>> >>> > parece que você está confundindo um pouco o conceito de threads.
>> >>> > quando uma thread é criada ela executa em paralelo ( assumindo que
>> sua
>> >>> > máquina possui vários nucleos e seu SO dá suporte à multi-threads ).
>> >>> >
>> >>> > o código que você citou espera a rotina terminar antes de iniciar
>> uma
>> >>> > nova iteração do loop, já com threads, o loop continua mesmo sem a
>> >>> > thread retornar, caso a tarefa seja grande o suficiente,
>> >>> >
>> >>> > o que o Buss falou está certo, então venho tentar adicionar algo à
>> mais,
>> >>> >
>> >>> > como você não menciona nada sobre controle de threads, talvez você
>> não
>> >>> > precise manter o controle das threads ao cria-las, então você pode
>> >>> > efetuar um detach nelas, o que significa descartar qualquer retorno
>> da
>> >>> > thread em questão. após um detach, a thread não poderá mais ser
>> >>> > controlada.
>> >>> >
>> >>> > caso queira esperar um thread específica retornar antes de criar as
>> >>> > outras você pode efetuar um join para aguardar o término da mesma,
>> >>> >
>> >>> > seria algo como:
>> >>> >
>> >>> > my $thr = threads->create(\&sub1);
>> >>> > $thr->detach; # não queremos saber sobre o retorno desta thread e
>> >>> > liberamos ela
>> >>> >
>> >>> > ou
>> >>> >
>> >>> > my $thr2 = threads->create(\&sub2);
>> >>> > my $resposta = $thr->join; # o retorno da sub2 atribuído à variável
>> >>> > escalar $resposta
>> >>> >
>> >>> > para o caso de você querer receber o resultado de cada thread
>> criada,
>> >>> > vale à ideía do Buss de criar um array no loop aonde as threads são
>> >>> > criadas,
>> >>> > ficando mais ou menos assim:
>> >>> >
>> >>> > my @pool_thr;
>> >>> > for (my $i =1; $i = 5; $i++){
>> >>> > $pool_thr[ $i ] = threads->create(\&sub1);
>> >>> > }
>> >>> >
>> >>> > sub sub1 {
>> >>> > ....
>> >>> > }
>> >>> >
>> >>> > quanto ao exemplo do servidor, mesmo com threads ou forks, enfim
>> >>> > vários processos em paralelo, você ainda terá outro provável
>> gargalo,
>> >>> > que é a parte de rede,
>> >>> >
>> >>> > abs.
>> >>> > Japa
>> >>> >
>> >>> > 2012/3/11 Aureliano Guedes <guedes_1000 em hotmail.com>:
>> >>> >> Na verdade, eu acho que minha pergunta que foi feita de forma
>> errada.
>> >>> >> Eu queria, por exemplo, dar ping em um servidor ate derruba-lo,
>> contudo
>> >>> >> eu
>> >>> >> queria para isso enviar digamos, 5 pacotes simultaneos,
>> >>> >> inves de enviar 1 por vez.
>> >>> >>
>> >>> >> Mas eu entendi quanto a usar o laço, talvez eu realmente faça isso.
>> >>> >> Contudo,
>> >>> >> usar
>> >>> >>
>> >>> >> for (my $i =1; $i <= 5; $i++){
>> >>> >> my $thr = threads->create(\&sub1);
>> >>> >> }
>> >>> >>
>> >>> >> não é o mesmo que usar apenas
>> >>> >>
>> >>> >>
>> >>> >> for (my $i =1; $i <= 5; $i++){
>> >>> >> &sub1;
>> >>> >> }
>> >>> >>
>> >>> >> se a função do meu sub1 for apenas enviar pacotes a um servidor???
>> >>> >>
>> >>> >> ________________________________
>> >>> >> From: bruno.buss em gmail.com
>> >>> >> Date: Sun, 11 Mar 2012 22:29:06 -0300
>> >>> >>
>> >>> >> To: rio-pm em pm.org
>> >>> >> Subject: Re: [Rio-pm] Multi threads
>> >>> >>
>> >>> >> 2012/3/11 Aureliano Guedes <guedes_1000 em hotmail.com>
>> >>> >>
>> >>> >> Opa, Bruno, valeu a resposta, mas vamos ver se eu entendi
>> >>> >>
>> >>> >> eu poderia fazer assim:
>> >>> >>
>> >>> >> use threads;
>> >>> >>
>> >>> >>
>> >>> >> for (my $i =1; $i = 5; $i++){
>> >>> >> my $thr = threads->create(\&sub1);
>> >>> >>
>> >>> >>
>> >>> >> sub sub1 {
>> >>> >>
>> >>> >> }
>> >>> >> }
>> >>> >>
>> >>> >> Mas assim não ocorreria execução simultanea, certo? Pois cada
>> execução
>> >>> >> iria
>> >>> >> ocorrer uma por vez a cada contagem do contador.
>> >>> >>
>> >>> >>
>> >>> >> A resposta para sua pergunta: errado.
>> >>> >> Porém sua explicação está "correta"... a cada iteração do for, será
>> >>> >> criada
>> >>> >> uma nova thread, então você terá disparado diversas threads até o
>> final
>> >>> >> do
>> >>> >> for.
>> >>> >>
>> >>> >> Agora, o ponto em ser simultâneo é um pouco mais complicado:
>> depende de
>> >>> >> quantos cores tem seu sistema (se tiver menos cores que threads
>> >>> >> utilizadas,
>> >>> >> então as threads estarão executando de forma concorrente e não
>> >>> >> simultânea),
>> >>> >> depende do escalonador de tarefas do seu sistema operacional,
>> dependo
>> >>> >> do que
>> >>> >> a sua sub1 faz, etc.
>> >>> >>
>> >>> >> Mas acho que a sua dúvida é um pouco mais básica do que isso...
>> >>> >>
>> >>> >> Fazer:
>> >>> >> for (my $i =1; $i <= 5; $i++){
>> >>> >> [alguma coisa]
>> >>> >> }
>> >>> >>
>> >>> >> é essencialmente igual a fazer [alguma coisa] 5 vezes (tirando o
>> fato
>> >>> >> que
>> >>> >> você pode utilizar o parâmetro do for para fazer alterações):
>> >>> >> [alguma coisa]
>> >>> >> [alguma coisa]
>> >>> >> [alguma coisa]
>> >>> >> [alguma coisa]
>> >>> >> [alguma coisa]
>> >>> >>
>> >>> >> No seu caso,
>> >>> >> for (my $i =1; $i <= 5; $i++){
>> >>> >> my $thr = threads->create(\&sub1);
>> >>> >> }
>> >>> >>
>> >>> >> É igual a fazer:
>> >>> >> my $thr = threads->create(\&sub1);
>> >>> >> my $thr = threads->create(\&sub1);
>> >>> >> my $thr = threads->create(\&sub1);
>> >>> >> my $thr = threads->create(\&sub1);
>> >>> >> my $thr = threads->create(\&sub1);
>> >>> >>
>> >>> >> Que é exatamente o que você queria, não? ;-)
>> >>> >>
>> >>> >> [ ]'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
>> >>> >>
>> >>> >> _______________________________________________
>> >>> >> Rio-pm mailing list
>> >>> >> Rio-pm em pm.org
>> >>> >> http://mail.pm.org/mailman/listinfo/rio-pm
>> >>> _______________________________________________
>> >>> Rio-pm mailing list
>> >>> Rio-pm em pm.org
>> >>> http://mail.pm.org/mailman/listinfo/rio-pm
>> >>
>> >> _______________________________________________
>> >> Rio-pm mailing list
>> >> Rio-pm em pm.org
>> >> http://mail.pm.org/mailman/listinfo/rio-pm
>> > _______________________________________________
>> > Rio-pm mailing list
>> > Rio-pm em pm.org
>> > http://mail.pm.org/mailman/listinfo/rio-pm
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>>
>>
>> _______________________________________________ Rio-pm mailing list
>> Rio-pm em pm.org http://mail.pm.org/mailman/listinfo/rio-pm
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
--
Tiago B. Peczenyj
Linux User #405772
http://pacman.blog.br
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120312/c74793d0/attachment-0001.html>
Mais detalhes sobre a lista de discussão Rio-pm