Comentários do Blog

Mandou muito bem cara!!! Parabéns!

execelente artigo, vale ouro mesmo ....

Muito bom cara! Script muito bem bolado... Parabéns!!

Hum.... Mais um pra minha lista de compras! Obrigado e Feliz Natal!!!

Sim, as trocas de contexto ocorrem. Porém, alternar entre threads é bem menos custoso que alternar entre processos. O livro Linux Kernel Development, do Robert Love, explica muito bem esse tópico.

No caso da aplicação que eu construí (servidor de conexões para gerência) não havia comunicação entre os processos. Se não me engano, a troca de contexto ocorre com thread também pelo conceito de 'multiplexação' do processador.

CopyOnWrite, interessante isso... Vou dar uma pesquisada!

Cara, recomendo muito o vídeo, mesmo ele tendo 61 min... O título diz tudo 'Mindblowing Python GIL'.

Não é isso. O overhead que me refiro são as constantes trocas de contextos ocasionadas pelo uso de pipes, sockets e outros mecanismos de comunicação entre processos. Ou seja, ao trabalho dispendioso que o SO tem de substituir a entrada da tabela de processos, memória paginada e outros recursos necessários.

Quanto a essa questão do fork, o Linux tabalho com o CopyOnWrite. Ele só realiza a cópia da memória do processo pai para o filho caso um desses tente sobreescrever uma área comum. Por exemplo, uma variável que armazene um arquivo de configuração. Ao ser chamado, o fork não faz a cópia dessa variável. Porém, caso o processo pai ou filho tente modifica-lo, pela regras de isolamento entre processo, a área de memória deixa de ser compartilhada e são feitas cópias específicas da variável para os processos envolvidos.

Rapaz, vou dar uma lida nessas referências que você me passou. Como eu sempre rodei diversas aplicações multithread simultaneamente, em Python e C, nunca havia notado pois os gráficos de utilização do processador mostram todos os núcleos ocupados. Então, talvez o fork ou acoplação fraca seja a melhor solução para aplicações escritas em Python.

Vou pesquisar sobre o assunto! Obrigado pelas referências.

Cara, usei fork para criar um servidor de conexões remotas. Eu achei que era o melhor modelo. Na época os ambientes multiprocessados não estavam "disponíveis" a todos então não analisei dessa ótica.

Hoje em dia eu também não sei se faria muita diferença pois, com essa 'fartura' de recursos computacionais, talvez fosse mais interessante pensar em Computação Distribuída através de clusters. Isso dependendo do seu objetivo, claro!!

Quanto ao overhead, você se refere à cópia de todas as variáveis que o fork faz?? Se for isso, existe também o vfork que cria somente referências das variáveis do processo pai.

Agora a parte triste disso tudo... O python tem uma série de restrições ao rodar em computadores multicore por causa do GIL (Global Interpreter Lock). O GIL impede que o mesmo bytecode seja rodado simultaneamente por mais de um processo. Resultado disso, temos uma computação serial, nada de paralelo.

Mas quem sou eu para explicar isso ... Vou deixar isso para quem entende: esse texto: Python's GIL is EVIL | GroupLens Research e esse vídeo: Mindblowing Python GIL . Ambos sobre Python & GIL.

@code

Como os princípios básicos de multithreading estão todos nesse artigo, não precisarei ralar muito para criar o de Python e Java, apesar de ambas as linguagens possuírem um modelo de threads bem diferente do POSIX.

@Magnum

Concordo em tudo que você falou. Mas não gosto muito de 'forks'. Na minha opnião, adiciona muito overhead que, a menos que se tenha um motivo bastante específico, é desnecessário. Porém, acho o assunto bastante interessante e vou fazer um texto em breve. E isso já dá para um terceiro texto e o levante de uma questão bastante polêmica: o que é melhor para aplicações paralelas em ambientes multiprocessadores, multi-threading ou IPC?

ps: Confesso que já tive alguns "motivos bastantes específicos" :-) Ou seja, se usar o fork for a alternativa mais adequada, uso sem pestanejar!

Cara, isso me lembra muito quando ralei pra usar pthreads no meu projeto de graduação!!! Você podia ter postado isso a 2 anos atrás, teria me poupado muito trabalho !!!!!

Posso sugerir outro post?? Sub-processos com o fork. Sub processos é outro assunto que embola a cabeça dos programadores no início mas possui funcionalidades excepcionais. Sem contar que os conceitos de semaforos e pipes (para comunicação) são essenciais para algumas aplicações...