[Rio-pm] Multi threads
Aureliano Guedes
guedes_1000 em hotmail.com
Segunda Março 12 05:54:57 PDT 2012
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
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120312/afe25a46/attachment-0001.html>
Mais detalhes sobre a lista de discussão Rio-pm