At 20:42 9/7/2001 -0300, Edgard Lemos wrote:
>A vers�o 2.0 do Apache parece resolver os dois problemas numa cajadada
>s�. Multithread para POSIX e interface nativa para Windows.
>
>Mas a minha pergunta � o seguinte: o que o Linux faz para tratar
>threads e processos do mesmo modo? A maneira como Linux trata os
>processos d� algum ganho de modo que fique t�o r�pido quanto se os
>tratasse como threads?
Os outros sistemas operacionais sao sistemas microkernel, escritos para
trabalhar em ambiente de multiprocessamento sim�trico. Nesse ambiente,
aplicacoes multithreaded tomam vantagem, pois v�rias camadas de execu��o
podem 'espalhar-se' nos v�rios processadores executando blocos de instru��o
simetricamente. Mas nesses sistemas, por uma razao de performance, o c�digo
para context-switching, que trata 'revezamento' entre processos geralmente
roda dentro do microkernel, enquanto o codigo de gerenciamento de memoria
reservada aos processos fica uma camada acima, sendo uma operacao penosa
fazer fork's de processos nesses sistemas, pois para cada um ele teria que
se reportar ao c�digo q est� na camada superior para fazer alocacao de
memoria, abrir descritores de arquivo etc. Para entender context-switching,
� bom saber que sistemas operacionais multitarefa reservam para cada tarefa
tem um tempo X para permanecer no processador, e encerrado esse tempo passa
para outra tarefa q esteja na fila de execucao.
Na verdade, a ideia por tr�s do design desses sistemas operacionais � que a
criacao de novos processos seja uma coisa muito rara, sendo apenas um
'trip�' para as threads, pois o processamento de instrucoes se daria nessas
threads compartilhando o mesmo espaco de memoria desses processos e �s
vezes os mesmos fds. Entao, a propria engine de context-switching (ou
agendador) se encarregaria de espalhar esses blocos de execucao por cada
processador.
Em sistemas monoliticos como o Linux nao existe isso, e como o agendador
est� na mesma unica camada que o codigo que gerencia memoria, tempo
disponivel dos processadores e etc, � muito mais r�pido criar novos
processos de uma vez pois n�o h� necessidade de passar por uma camada para
reportar-se a uma entidade principal. Apesar de haver memoria protegida,
nao h� separacao em nivel de codigo entre gerenciamento de mem�ria do
nucleo, memoria dos servicos e memoria das aplicacoes, e em Linux e outros
unixes gratis convencionou-se tornar tudo um processo por questao de
eficiencia. Como as threads deveriam compartilhar a mesma memoria do seu
processo pai, para que o kernel monolitico nao possa confund�-las com o
mesmo processo � aberta uma nova entrada para cada thread na tabela de
processos, e desse jeito novos file descriptors sao abertos, e alguma
memoria a mais � alocada para cada thread. Assim, as threads podem
conversar entre si com um segmento diferente de memoria compartilhada, mas
nao com a mesma onde deveriam estar operando. No caso do Apache, onde sao
abertos alguns poucos processos (ou threads, na versao 2) isso �
extremamente eficiente! Mas n�o escala, pois em aplicacoes com dezenas,
centenas ou milhares de threads cada uma � tratada como um processo
diferente, consumindo memoria exponencialmente, abrindo mais file
descriptors e saturando o scheduler. No caso de maquinas com multiplos
processadores, a distribuicao de tarefas fica prejudicada pois como o
kernel fica ocupado demais alocando e desalocando memoria, revezando tempo
de tarefas em cada processador e tratando descritores de arquivo pra cima e
pra baixo, tudo ao mesmo tempo, isso gera lat�ncia e alguns processadores
acabam ficando tempo demais ociosos sem tarefas para executar, pois quanto
mais processadores, mais o tempo disponivel ser� dividido tanto com os
outros chips como com os processos, gerenciamento de memoria e threads, o
que � um dos motivos q o Patola falou de pq o Linux nao escala na mesma
propor��o em q se adiciona processadores. Uma hora a m�quina simplesmente
vai pedir arrego =). Como consertar isso? N�o d�, isso � decidido em tempo
de projeto. Teria q ser reescrito todo o kernel, como eu comentei em
diversas mensagens anteriores. Esse foi um dos principais motivos pelos
quais a Sun abandonou a base de codigo BSD antiga do SunOS e adotou um
microkernel para o Solaris.
Leitura recomendada:
* Sistemas operacionais modernos - Andrew Tanembaum - Prentice Hall do Brasil
* Sistemas operacionais - William Shay - Makron
* Como funciona seu computador :) (� um livrinho ilustrado, fino e grande,
com ilustracoes mostrando o processo de funcionamento de um computador do
boot ao prompt. Nao lembro o autor, vi lah na biblioteca da T�cnica)
* Arquitetura de sistemas operacionais - Francis Machado - LTC
Todos esses vc encontra nas bibliotecas da maioria das universidades.
Esse � um artigo muito bom sobre multithreading em n�vel de hardware, q
saiu recentemente no Slashdot:
http://www.systemlogic.net/articles/01/6/multithreading/
Se eu nao me engano, h� algum material sobre threading no site da Ars
Technica (www.arstechnica.com), mas eu nao guardei o link
--
Thiago Pimentel
Preview Tecnologia
Pra qu� levar tudo t�o a s�rio, se a vida � uma alucinante viagem da qual
jamais sairemos vivos...
-- Bob Marley
Assinantes em 10/07/2001: 2256
Mensagens recebidas desde 07/01/1999: 122293
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
