Novo sistema de threads

Qual é a diferença entre thread e
processo?

[]

Sou leigo no assunto, por isso quero saber no q isso pode influenciar minha vida de usuário linux.

Simples,

Um processo pode otimizar seu desempenho criando outros processos para distribuir as tarefas que tem a fazer.

A abordagem mais simples é você criar simplesmente um novo processo, chamado processo filho. Ele, sob todos os aspectos, é igual a um processo qualquer: tem sua própria fatia de CPU e contexto de memória.

No entanto, os subprocessos criam um gasto adicional com memória, além do fato de que o SO tem que enviar os dados que deseja com os quais o subprocesso trabalhe, por meio de canais ("pipes"), o que prejudica o desempenho.

Por outro lado, um thread é um subprocesso que compartilha o contexto de memória do processo-pai, de maneira que ele tem acesso aos dados necessários para trabalhar sem nenhuma medidad adicional.

Respondendo a segunda pergunta, sistemas UNIX são, tradicionalmente, criados com o objetivo de oferer um bom desempenho com threads, ao contrario do Windows que pena bastante para fazer isso.

Mas onde é usado? Por exemplo, um servidor TCP qualquer, precisa criar um processo filho por requisição. Daí, quanto melhor o desempenho na criação de threads, menor a taxa de latência para responder as requisições, e melhor o desempenho global do servidor (pense em Apache, Sendmail, etc..., o Apache é um servidor que se aproveita bastante da abordagem dos threads).

"Respondendo a segunda pergunta, sistemas UNIX são, tradicionalmente, criados com o objetivo de oferer um bom desempenho com threads, ao contrario do Windows que pena bastante para fazer isso."

Pô, essa nem o mais fanático por Unix eu achava que diria. Desculpa mas o desempenho dos threads do Windows é reconhecido por ser muito melhor que o dos Unixes em geral. Não queria citar aqui o conhecido "apelo à autoridade", mas recentemente numa conversa pessoal com meu ex-chefe, que é um dos melhores profissionais de Unix corporativo aqui do Brasil, ele estava me falando de como o desempenho das threads no Windows é muito melhor do que nos Unixes e no GNU/Linux. Só a palavra dele não vale nada, mas procure sob esse assunto na net que você encontra referências fácil fácil. Aliás, eu comentei algumas coisas na discussão sobre a mesma notícia da PontoBR: http://pontobr.org/article.php?sid=19

Mas se estamos falando de um novo mecanismo de threads que inicia e finaliza mais de 100.000 threads em 2 segundos, provavelmente estamos falando de algo que terá um desempenho muito superior ao Windows...

A maior diferença entre um processo e um thread está no espaço de endereçamento utilizado, particularmente o código do programa. Os threads não precisam de uma mudança de contexto mais detalhada, pois não precisa mudar os endereços das páginas de memória acessadas nos registradores da CPU quando alterna de um thread para outro, como acontece nos processos, tendo um desempenho melhor.

Entretanto, essa solução é particularmente útil quando se precisa realizar o mesmo programa, mas com argumentos diferentes, e podem tanto ser implementadas diretamente pelo kernel quanto através de bibliotecas, sendo o gerenciamento de threads feita pelo próprio programa ao invés do kernel.

Ambas as soluções, kernel e biblioteca, possuem vantagens e desvantagens, sendo inicadas cada uma para um determinado tipo de serviço.

Um bom lugar pare ler sobre threads é o livro "Sistemas Operacionais - Conceitos, de Silbershatz e Galvin"

Pô, Patola,
eu acho que não é bem assim. Eu já tive uma máquina com dois processadores. No linux, voava baixo. Não tinha conversa, pediu, levou.
Agora, no windows... Estou falando do windows 2000 com o suporte a multiprocessamento.
Por essa experiência, posso concluir que o unix parece que foi feito para os threads mesmo.
Threads é um recurso que acelera a máquina até em um sistema monoprocessado e suga tudo de um multiprocessado. Sabendo disso, e supondo que o windows é melhor nessa área, por que os programas windows não utilizam dessa tecnologia tanto quanto o unix??? Mesmo os do windows 98, 95, me ...
Eu sugava tudo do meu sistema multiprocessado devido a inúmeros programas utilizarem essa técnica, até mesmo jogos, como o quake e o unreal tournament, onde o fps era 30% maior que no windows. Só 30% porque a parte do video, que é a mais pesada, era feita em um thread apenas, segundo o pessoal da loki games. Detalhe que os jogos não eram preparados para sistemas multiprocessados e, mesmo assim, tinha fps 30% maior.
Teu ex-chefe, não sei não...

/*
Um exemplo bem simples de thread
O problema do barbeiro...
pra compilar
gcc essearquivo.c -lpthread -o essearquivo.bin
pra rodar
./essearquivo.bin
depois abra um outro terminal (nao mate o esse programa) e de um $pstree -a
*/
#include
#include
#include
#include
#define NUM_CADEIRAS 8

pthread_mutexattr_t mutex_attr;
pthread_mutex_t trava_caixa;

sem_t cadeiras_de_espera;
sem_t barbearia_vazia;
sem_t parte;
sem_t fora;

int caixa=0;

void proc_barbeiro(void *ptr);
void proc_client(void *ptr);

int main(void){
pthread_t barbeiro;
pthread_t *ptr_sur_thread;
sem_init(&cadeiras_de_espera, 0, NUM_CADEIRAS);
sem_init(&barbearia_vazia, 0, 0);
sem_init(&parte, 0, 0);
sem_init(&fora, 0, 0);
pthread_mutex_init(&trava_caixa, &mutex_attr);
pthread_create(&barbeiro, NULL, (void*)&proc_barbeiro, NULL);
while(1){
sleep(1);
printf("CLIENTE CHEGANDO...\n");
ptr_sur_thread=(void*)malloc(sizeof(pthread_t));
pthread_create((void*)&ptr_sur_thread, NULL, (void*)&proc_client, NULL);
}
pthread_join(barbeiro, NULL);
}
void proc_barbeiro(void *ptr){
int i;
printf("BARBEIRO: Vou abrir a barbearia\n");
while(1){
sem_getvalue(&barbearia_vazia, &i);
if(i==0){
pthread_mutex_lock(&trava_caixa);
i=caixa;
pthread_mutex_unlock(&trava_caixa);
printf("BARBEIRO: Nao tenho clientes ,vou dormir tenho R$%i ate agora.\n",i );
}
sem_wait(&barbearia_vazia);
sem_post(&parte);
printf("BARBEIRO: Vou atender um cliente.\n", i);
sleep(2);
i=caixa;
printf("BARBEIRO: Terminei de atende-lo ,tenho R$%i ate agora.\n",i);
sem_post(&fora);
}
}
void proc_client(void *ptr){
int i;
printf("CLIENTE: cheguei\n");
sem_getvalue(&cadeiras_de_espera, &i);
printf("CLIENTE: Tem %i cadeira(s) livre(s).\n", i);
sem_wait(&cadeiras_de_espera);
printf("CLIENTE: Vou sentar numa cadeira para esperar\n", i);
sem_post(&barbearia_vazia);
sem_wait(&parte);
sem_post(&cadeiras_de_espera);
printf("CLIENTE: Agora eh minha vez...serei atendido.\n");
pthread_mutex_lock(&trava_caixa);
caixa=caixa+10;
pthread_mutex_unlock(&trava_caixa);
sem_wait(&fora);
printf("CLIENTE: Meu cabelo ficou otimo ,vou voltar pra casa.(paguei R$10)\n");
}

foi mal galera os includes nao sairam (nao sei pq)
#include stdio.h
#include unistd.h
#include pthread.h
#include semaphore.h
nao esquecam de fechar com maior/menor :)
lets compile it!

Análise de desempenho de threads NT x Solaris (conclusão: o NT é muito bom em threads sem sincronização, o Solaris é bom quando se usam muitos mutexes) http://www.usenix.org/publications/library/proceedings/usenix-nt98/full_papers/zabatta/zabatta_html/zabatta.html

Comparação de implementações de threads em vários SOs: http://members.aol.com/drbutenhof/ThreadTable.html

Comparação de threads Linux, Solaris e Windows NT: http://www.northco.net/chenke/project/project2.html

E uma excelente explicação da Windows 2000 Magazine (resumida e direta ao assunto) de porque o desempenho de threads no Linux é ruim: http://www.win2000mag.com/Articles/Index.cfm?ArticleID=4502

Eu daria ainda outra sugestão. Para verificar a minha declaração sobre o "threadismo", pegue o programa robode - http://www.robocode.alphaworks.ibm.com - e rode ele em Windows e GNU/Linux (é em Java). Primeiro rode com apenas dois ou três robôs (cada robô é um thread). Depois rode com uns 15. Você verá que no Windows ele estará MUITO mais rápido! Para garantir justiça na avaliação, tente rodá-lo tanto com a JVM 1.4 da Sun quanto a 1.3.1 da IBM.

Galera, eu amo GNU/Linux, mas se a gente não aprender a identificar as falhas do sistema, nunca as consertaremos. Sim, threads é uma delas!

Oi Patola !!!
Sem ir muito fundo no assunto, mas tenho um exemplo bom aqui para a discussão: saindo do mérito de velocidade, eu tenho um programinha que usa sockets e foi escrito sem o nonblocking do Java, que só chegou agora na 1.4, então para cada cliente ele usa uma thread, usando o thread pooling para dar uma otimizada na coisa ...
Quando rodei pela primeira vez em um NT (em um hardware parrudinho), *sem* o pooling, o cria/mata das threads "derrubou" o NT, coitado ehehe, comia muitos recursos ...
Após a implementação do pooling, ele rodava legal, mas como todo bom rwindows um dia o bicho "morria", e lá vai a gente fechar e iniciar o programa de novo. A chefe aqui (argh, detesto chamar aquela dona disso) fugia do Linux como o capeta da cruz, então sem chance de fazer uma experiencia com o bichinho. Quando o povo se tocou que a jararaca não sabia nem formatar disquete mais e mandou ela embora, a gente colocou Linux pra tudo quanto é canto, e esse programinha agora tá rodando num Pentium III com Linux, e nunca mais me deu dor de cabeça. :-)
Como disse, fugindo do conceito de velocidade, a estabilidade das threads do Linux, mesmo precisando de alguns ajustes ainda, é pelo menos bem mais estável que as do NT foram. Pelo menos é minha impressão até agora, por que nunca mais deu problema. :-)
Puxando a coisa pro lado do Java agora, com o NIO lançado na 1.4, acredito que vai dar pra reduzir drasticamente operações multithreading, apesar que algumas vezes o uso é inevitável.
Abração

Os threads são tão coxas no linux que são processos "mascarados". Ainda bem que isso vai mudar.
O desempenho ruim de threads no Linux é reconhecido, tanto que o Apache 2 roda com forks no Linux e com novos threads no Windows.
Em comenpensação é nojento criar novos processos no Windows... praticamente vc tem que compilar tudo em outro binário...

Só lembrando que é no Linux esse problema. Outros Unix usam cada um seu próprio kernel, não confundam...