BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Comparação do Kernel dos 3 SO mais utilizados

Comparação do Kernel dos 3 SO mais utilizados

A idéia de escrever este artigo foi baseado na visão de Max Bruning sobre Solaris, BSD e Linux. A comparação das vantagens e desvantagens entre sistemas quasi-Unix é uma fábula contada frequentemente. Entretanto, este artigo apresenta uma visão dos três subsistemas do kernel dos últimos lançamentos dos seguintes sistemas operacionais - OpenSolaris, Windows Vista e o kernel Linux 2.6. A razão mais simples é que estes são os sistemas operacionais mais bem vistos e utilizados dentro dos ambientes corporativos e nas comunidades de desenvolvedores.

Existem diversos critérios para avaliar um sistema, mas sem dúvida, o papel principal de um sistema operacional dentro da ciência da computação continua inalterado. E pode ser visto como detentor de três objetivos:

  • Eficiência: permitir que os recursos do sistema (especialmente hardware) sejam utilizados de uma maneira eficiente..
  • Evolução: A única coisa que nunca muda é a evolução. O SO deve ser construído de maneira que permita o desenvolvimento efetivo e a possibilidade de introduzir novas funções sistêmicas sem interferir com o serviço original.
  • Interface amigável: Nós precisamos encarar o SO todos os dias. Uma interface amigável é obrigatório, senão você estará fora, não interessa o quão bem você seguir os dois critérios acima.

Inevitavelmente, um SO precisa de funções como gerenciamento de processos/thread, que alocam e efetuam chamadas a threads sob uma política de emissão em particular, gerenciamento de memória e gerenciamento de arquivos. Nós vamos comparar estes subsistemas ponto a ponto. (Interface com usuário não será discutido neste artigo, uma vez que estamos focando em comparação no kernel) Existem alguns conceitos similares entre Linux e o OpenSolaris, enquanto que os conceitos no Windows Vista são totalmente diferentes.

Gerenciamento de Thread e Processos

OpenSolaris

OpenSolaris implementa um suporte de thread multilevel desenhado para fornecer uma flexibilidade considerável na exploração dos recursos do processador. Os quatro novos conceitos a seguir são implementados no OpenSolaris.

  • Processo: Este é o processo normal do UNIX e inclui o espaço de endereço do usuário, stack, e o bloco de controle de processos.
  • Thread de nível do usuário: Implementado por uma biblioteca de threads em um espaço de endereço de um processo, estas threads são invisíveis para o SO. Uma thread de nível de usuário (ULT)10 é uma unidade criada pelo usuário de execução dentro de um processo.
  • Processos lightweight: Um processo lightweight (LWP) pode ser visto como um mapeamento entre as threads de nível do usuário e as threads do kernel. Cada LWP suporta ULT e a mapeia para uma thread de kernel. LWPs são scheduladas independentemente pelo kernel e podem executar em multi-processadores paralelamente.
  • Threads do Kernel: Esta são as entidades fundamentais que podem ser scheduladas e enviadas para execução em um dos processadores do sistema.

Conforme demonstrado na Figura 0, o comando ps -Lec apresenta os processos do sistema e as threads. 

Figura 0 Saída do Solaris 10 update 6

Figura 1 abaixo ilustra o relacionamento entre estas quatro entidades.

Figura 1 modelo de threads do opensolaris1

A estrutura de threads de três níveis (ULT, LWP, kernel thread) no OpenSolaris é para facilitar o gerenciamento de threads pelo SO e para fornecer uma interface limpa para as aplicações.

A interface de thread do usuário pode ser uma biblioteca de threads padrão. Uma ULT definida é mapeada para uma LWP, que por sua vez é gerenciada pelo SO que possui estados definidos de execução, definidos posteriormente. Uma LWP é limitada a uma thread de kernel com uma correspondência um-para-um em estados de execução. Desta maneira, concorrência e execução são gerenciados no nível do thread do kernel.

Além disso, uma aplicação possui acesso ao hardware através de uma application program interface (API) constituída de chamadas ao sistema.  A API permite que o usuário invoque serviços do kernel para realizar tarefas privilegiadas em favor dos processos chamados, como uma leitura ou escrita em um arquivo, emissão de um comando de controle para algum dispositivo, criação de um novo processo ou thread, alocação de memória para uso do processo, e assim por diante.

A mudança do modelo de threads conduz a alteração das estruturas de dados do processo. O OpenSolaris retém esta estrutura básica mas substitui o bloco de estado do processador com uma lista de estruturas contendo um bloco de dados para cada LWP.

A estrutura de dados do LWP inclui os seguintes elementos:

Um identificador LWP

  • A prioridade do LWP e a thread de kernel que o suporta
  • Uma máscara de sinal que diz ao kernel qual sinal será aceito
  • Valores salvos dos registros de nível do usuário (quando o LWP não esta em execução)
  • A pilha do kernel para o LWP, que inclui os argumentos de chamada ao sistema, resultados, e códigos de erro para cada nível de chamada
  • Uso de recursos e dados de profiling
  • Ponteiro para a thread de kernel correspondente
  • Ponteiro para a estrutura de processos

Figura 2 Comparação da estrutura de Processos do Solaris e de uma estrutura de Processos tradicional do Unix.

Windows Vista

O modelo de processos do Vista é impulsionado pela necessidade de fornecer suporte para uma variedade de ambientes SO. Assim, as estruturas dos processos nativos e os serviços oferecidos pelo Kernel do Windows são relativamente simples e generalistas, permitindo que cada subsistema do SO emule uma estrutura e funcionalidades de um processo em particular. Aqui estão algumas características importantes dos processos do Windows:

Processos do Windows são implementados como objetos.
Um processo executável pode conter uma ou mais threads.
Tanto os processos quanto os objetos thread possuem habilidades de sincronização embutido.

A figura 32 abaixo ilustra a maneira na qual um processo é relacionado aos recursos que ele controla ou utiliza. Para cada processo é atribuído um token de acesso de segurança, chamado de token primário do processo.

  • Processos do Windows são implementados como objetos.
  • Um processo executável pode conter uma ou mais threads.
  • Tanto os processos quanto os objetos thread possuem habilidades de sincronização embutido.

Figura 32 abaixo ilustra a maneira na qual um processo é relacionado aos recursos que ele controla ou utiliza. Para cada processo é atribuído um token de acesso de segurança, chamado de token primário do processo.

Figura 3 um processo windows e suas threads

Quando um usuário efetua login pela primeira vez, o Vista cria um token de acesso que inclui o ID de segurança para o usuário. Windows utiliza o token para validar a permissão de acesso do usuário para acessar objetos protegidos ou para realizar funções restritas no sistema e em objetos protegidos. O token de acesso controla onde o processo pode alterar seus próprios atributos. Neste caso, o processo não possui um meio aberto para seu token de acesso. Se o processo tentar abrir um meio de acesso, o sistema de segurança determina se ele possui permissão e avalia se o processo pode alterar seus próprios atributos.

Também relacionado ao processo, está uma série de blocos que definem o espaço de endereço do usuário corrente atribuído a este processo. O processo não pode modificar diretamente estas estruturas, mas deve contar com o gerenciador de memória virtual, que fornece um serviço de alocação de memória para o processo.

Por fim, o processo inclui um objeto tabela, que manipula outros objetos conhecidos para o processo. Existe um handle para cada thread contido neste objeto.

Além disso, o processo possui acesso ao file object e ao section object que define a zona de memória compartilhada.

A estrutura orientada a objeto do Windows facilita o desenvolvimento de um processo para propósitos gerais. O Windows Vista faz uso de dois tipos de objetos relacionados ao método: processos e threads. Assim como o OpenSolaris, um processo no Windows é uma entidade pertencente a uma tarefa do usuário ou a uma aplicação que possua recursos como memória e arquivos abertos. Uma thread é uma unidade executável de trabalho que é executada sequencialmente de forma ininterrupta, de maneira que o processador possa alternar para outra thread.

Windows Vista suporta concorrência entre processos porque threads em diferentes processos podem executar concorrentemente. Mais ainda, múltiplas threads dentro de um mesmo processo podem ser alocadas para processadores separados e ser executados simultaneamente. Um processo multithread consegue fazer concorrência sem o overhead de utilizar processos múltiplos. As threads dentro do mesmo processo podem trocar informações através de seus espaços de endereço em comum e ter acesso aos recursos compartilhados do processo. Threads em processos diferentes podem trocar informações pela memória compartilhada que foi estabelecida entre os dois processos.

Um processo multithread orientado a objeto é uma maneira eficiente de se implementar um servidor de aplicações. Por exemplo, um processo de servidor pode atender um certo número de clientes.

Linux Kernel 2.6

Um processo, ou tarefa, no Linux é representado por uma estrutura de dados chamada task_struct. A estrutura de dados task_struct contém informações em um número de categorias:

  1. Diferente dos processos do Vista e OpenSolaris, os processos no Linux são ambas entidades programáveis e containers; os processos podem compartilhar o espaço de endereço e os recursos do sistema, tornando os recursos efetivamente utilizáveis como as threads.
  2. Também diferente do Vista e OpenSolaris, a maioria dos serviços são implementados no kernel, com a exceção de muitas funções de rede. Desta maneira o kernel do Linux é relativamente maior em tamanho comparado aos dois primeiros SO.

Linux fornece uma solução única neste ponto, e não reconhece uma distinção entre threads e processos. Utilizando um mecanismo similar aos processos lightweight do OpenSolaris, as threads de nível de usuário são mapeadas para os processos do nível do kernel. Múltiplas threads de nível de usuário que constituem um único processo de nível de usuário são mapeados para os processos de nível de kernel do Linux que compartilham o mesmo ID de grupo. O que permite que estes processos compartilhem recursos como arquivos e memória, e para evitar a necessidade de uma mudança de contexto quando o scheduler alterna entre os processos do mesmo grupo.

Conclusão

Solaris e Windows ambos existem á muitos anos enquanto que o Linux é muito jovem com um grande caminho pela frente. Obviamente, os três SO foram implementados seguindo teorias populares de sistemas operacionais. A diferença mais gritante é a habilidade que temos de acessar a implementação do kernel e debugá-lo. Limitado ao meu conhecimento, eu não tenho como debugar ou rastrear um processo e uma thread no Windows Vista enquanto que o OpenSolaris ferramentas abundantes para analisar a thread do kernel.

 

No próximo artigo, nós iremos continuar a discutir o gerenciamento de memória e o sistema de arquivos.


1 Richard McDougall, Jim Mauro ,Solaris internals 2005 Pearson Education

2 Russinovich, M., and Solomon, D. Microsoft Windows Internals: Microsoft Windows Server(TM) 2003, Windows XP, and Windows 2000. Redmond, WA: Microsoft Press, 2005.

 

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT