Pular para o conteúdo principal

Threads e Eventos para calcular se um número é primo

Segue um pequeno programa que fiz para experimentar o uso Threads e Eventos do módulo threading de Python. A minha idéia foi definir um evento que pode estar ativo ou não e que controla o início e o término do processamento de cada Thread.

Ao dividir o trabalho de calcular se um número é primo em várias linhas de controle (Threads), teoricamente seria possível melhorar o tempo de processamento. Porém como essa aplicação é CPU bound , e como um processo do interpretador Python não permite que suas Threads executem de forma simultânea, cada qual em uma CPU ou núcleo físico, na prática esse exemplo acaba não sendo muito útil para esse caso, a não ser como prova de conceito.

Se a aplicação trabalhasse com o uso de entrada e saída, ou seja, IO bound, então já seria mais interessante, pois enquanto uma Thread poderia estar bloqueada fazendo a leitura ou gravação em um disco, enviando ou recebendo dados via rede ou esperando o resultado de uma consulta no banco de dados, as outras Threads poderiam estar executando, ocupando mais a CPU e consequentemente diminuindo o tempo total de execução do programa.

Segue link para acesso ao código, já que não consegui manter a formatação usando o editor do blogspot ou mesmo carregando o fonte do HTML gerado pelo Scite. :-(

Comentários

Anônimo disse…
Há um modo de programar em python usando uma ide simples como a do visual basic?
Você quer dizer usando uma IDE para desenhar interfaces gráficas (GUI) e programar?

A resposta é sim! Algumas ferramentas que possuem essa integração que eu conheço:

- Boa Constructor
- KDevelop usando PyQT

Além disso existem ferramentas para desenhar telas que não são integradas, mas que atendem bem a essa necessidade, como o Glade e o Gazpacho (GTK/Gnome).

Aqui você pode encontrar maiores informações também:

http://www.pythonbrasil.com.br/moin.cgi/IdesPython
Eduardo Rolim disse…
Olha, eu normalmente uso um site para postar meus códigos. Ele é excelente. Têm syntax highlight e contagem de linhas.

O endereço é www.pastebin.ca

Eu costumo usar ele para meus códigos agora.

Abração !!

Postagens mais visitadas deste blog

18 de junho agora é #dornelesday

Hoje é um dia muito especial, pois hoje é dia de homenagear uma grande pessoa: Dorneles Treméa. Pois ele, com seus gestos simples, paciência, perseverança e generosidade, se tornou um exemplo para muitas pessoas, no mundo todo, dentro da comunidade de Software Livre e mais especificamente na comunidade Python e Plone. Apesar de ter nos deixado tão jovem, o tempo é relativo, por isso, tenho certeza que ele deixou uma marca profunda na vida de todos que conviveram com ele. Seja pela paz e alegria que ele transmitia, sempre de bom humor nas mais difíceis situações, seja pela disposição eu ajudar quem lhe pedia auxílio, seja pela dedicação que tinha pela sua família. Por isso, para mim e para muitas pessoas, o dia 18 de junho é a partir de hoje #dornelesday, que representa um dia para refletir sobre tudo de bom que nosso colega e amigo trouxe para nós com seu exemplo de vida. Que todo dia possamos nos inspirar com esse exemplo e possamos aprender, um pouco que seja, com este legado. Na ver

RelStorage: ZODB usando backend relacional (SGDBs)

Introdução O ZODB (banco de dados orientado à objetos para aplicalções Python ), originalmente criado como um componente do servidor de Aplicação Zope2 ( Z Object Publishing Environment ) , foi desenvolvido com o conceito de "Storage Layer", o qual abstrai o tipo de backend responsável pela persistência dos objetos. Historicamente, o primeiro Storage Layer desenvolvido para o ZODB foi FileStorage, que tem como objetivo ser simples e robusto, e por isso armazena todos os objetos e transações um único arquivo de forma sequencial. Para acessar os objetos através do seu caminho na hieraquia de objetos do ZODB (ex: obj2 = root['obj1']['obj2'] ), o FileStorage cria um arquivo auxiliar de índice e que deve estar completamente na memória para que o desempenho seja adequado. Compartilhando o ZODB Mais tarde, devido a necessidade de compartilhar um mesmo banco de dados por diversas instâncias de uma aplicação (ou diversas aplicações), foi desenvolvido o ZEO (Zope Ente

Como explodir seu buildout com Plone 2.5 e Five 1.4?

Já faz algum tempo que a melhor forma de realizar deploy de projetos Plone passou a ser a utilização da ferramenta zc.buildout , também chamada apenas de buildout . É realmente incrível como ela facilita a tarefa de criar ambientes tanto para produção como desenvolvimento de forma simples, rápida e fácil, mesmo nos mais complexos cenários. Tudo isso graças a sua arquitetura, a qual permite a utilização de diferentes receitas ( recipes ), desde que elas sejam publicadas como um pacote Python no PyPi , e assim podem ser reutilizadas por qualquer um que necessite da mesma funcionalidade. Na verdade, o buildout pode (e deve) ser usado por quaisquer projetos, não se limitando apenas ao Zope e seus compatriotas como o Plone e Grok , e já vem sendo usado em projetos Django também. Porém, existem vantagens e desvantagens de se utilizar o buildout para o deploy de projetos de software . Na minha opinião, as vantagens são muito maiores que as desvantagens. A principal vantagem é a cap