O Sistema Mach
B
Neste apêndice, examinamos o sistema operacional Mach. O
Mach é projetado para incorporar as diversas inovações recen-
tes da pesquisa em sistemas operacionais e produzir um sis-
tema totalmente funcional e tecnicamente avançado. Diferente
do UNIX, que foi desenvolvido sem preocupação com mul-
tiprocessamento, o Mach incorpora suporte total a multi-
processamento. Seu suporte a multiprocessamento também
é excessivamente flexível, acomodando sistemas de memória
compartilhada assim como sistemas sem memória comparti-
lhada entre processadores. O Mach é projetado para operar em
sistemas de computação de um até milhares de processadores.
Além disso, ele é mais facilmente portado para muitas arquite-
turas de computadores diferentes. Um objetivo-chave do Mach
é ser um sistema distribuído capaz de funcionar em hardwares
heterogêneos.
B.1 História do Sistema Mach
A linhagem do Mach vem do sistema operacional Accent
desenvolvido na Carnegie Mellon Universisty (CMU). Embora
o Accent tenha sido pioneiro em vários conceitos novos de sis-
temas operacionais, sua utilidade era limitada pela incapaci-
dade de executar aplicações UNIX e por seus fortes vínculos
com uma arquitetura de hardware específica, o que tornava
difícil sua portabilidade. O sistema de comunicação e a filosofia
do Mach derivam do Accent, mas muitas outras partes signifi-
cativas do sistema (por exemplo, o sistema de memória virtual
e o gerenciamento de tarefas e threads) foram desenvolvidas a
partir do zero. Um objetivo importante do esforço do Mach foi
o suporte a multiprocessadores.
O desenvolvimento do Mach seguiu um caminho evo-
lucionário a partir dos sistemas BSD UNIX. O código do
Mach foi, inicialmente, desenvolvido dentro do kernel do
4.2 BSD, com os componentes do kernel do BSD sendo subs-
tituídos por componentes do Mach à medida que esses com-
ponentes eram concluídos. Os componentes do BSD foram
atualizados para o 4.3 BSD quando ele se tornou disponí-
vel. Por volta de 1986, os subsistemas de memória virtual e
comunicação estavam sendo executados na família de com-
putadores VAX DEC, inclusive em versões multiprocessado-
ras do VAX. Versões para o IBM RT/PC e para estações de
trabalho Sun 3 vieram em seguida; o ano de 1987 viu a con-
clusão das versões multiprocessadoras Encore Multimax e
Sequent Balance que incluíam suporte a tarefas e threads,
assim como os primeiros releases oficiais do sistema, Rele-
ase 0 e Release 1.
APÊNDICE
Embora muitos sistemas operacionais experimentais este-
jam sendo projetados, construídos e usados, o Mach atende
melhor às necessidades das massas do que os outros sistemas
porque oferece compatibilidade total com o UNIX 4.3 BSD.
Portanto, ele fornece uma oportunidade única para compa-
rarmos dois sistemas operacionais funcionalmente semelhan-
tes, mas diferentes internamente. O Mach e o UNIX diferem
em suas ênfases e, assim, nossa discussão do Mach não é
exatamente paralela à discussão do UNIX. Além disso, não
incluímos uma seção sobre a interface de usuário porque esse
componente é semelhante à interface de usuário do 4.3 BSD.
Como você verá, o Mach também fornece o recurso de emu-
lação de camadas de outros sistemas operacionais; outros
sistemas operacionais podem até mesmo executar concorren-
temente com o Mach.
Por intermédio do Release 2, o Mach fornece compatibili-
dade com os sistemas BSD correspondentes ao incluir grande
parte do código do BSD no kernel. Os novos recursos e fun-
cionalidades do Mach tornam os kernels desses releases maio-
res do que os kernels BSD correspondentes. O Mach 3 (Figura
B.1) transfere o código do BSD para fora do kernel, deixando um
microkernel muito menor. Esse sistema implementa no kernel
apenas recursos básicos do Mach; todo o código específico do
UNIX tem sido removido para operar em servidores de moda-
lidade de usuário. A remoção de código específico do UNIX do
kernel permite a substituição do BSD por outro sistema opera-
cional ou a execução simultânea de várias interfaces de sistemas
sistema de
banco
de dados
tarefas IPC memória scheduling
e threads virtual
Mach
Figura B.1 Estrutura do Mach 3.

operacionais acima do microkernel. Além do BSD, implemen-
tações de modalidade de usuário têm sido desenvolvidas para
DOS, o sistema operacional Macintosh e o OSF/1. Essa abor-
dagem tem semelhanças com o conceito de máquina virtual,
mas a máquina virtual é definida por software (a interface do
kernel do Mach) e não por hardware. A partir do Release 3.0, o
Mach tornou-se disponível em uma ampla variedade de siste-
mas, incluindo máquinas de processador único Sun, Intel, IBM
e DEC e sistemas multiprocessadores DEC, Sequent e Encore.
O Mach tomou a dianteira na indústria quando a Open
Software Foundation (OSF) anunciou em 1989 que usaria
B.2 Princípios de Projeto
O sistema operacional Mach foi projetado para fornecer meca-
nismos básicos que faltam na maioria dos sistemas opera-
cionais atuais. O objetivo é projetar um sistema operacional
que seja compatível com o BSD e, além disso, se destaque nas
seguintes áreas:
• Suporte a arquiteturas diversificadas, incluindo multi-
processadores com vários níveis de acesso compartilhado
à memória: acesso uniforme à memória (UMA), acesso
não uniforme à memória (NUMA) e sem acesso remoto à
memória (NORMA – no remote memory access)
• Capacidade de funcionar com velocidades variadas de redes
entre computadores, das redes de longa distância às redes
locais de alta velocidade, e com multiprocessadores forte-
mente acoplados
• Estrutura do kernel simplificada, com pequeno número de
abstrações (por sua vez, essas abstrações são suficientemente
genéricas para permitir que outros sistemas operacionais
sejam implementados acima do Mach)
• Operação distribuída, fornecendo transparência de rede aos
clientes e uma organização orientada a objetos tanto interna
quanto externamente
• Integração entre gerenciamento de memória e comunica-
ção entre processos para fornecer comunicação eficiente de
grandes volumes de dados, assim como gerenciamento de
memória com base em comunicação
• Suporte a sistemas heterogêneos para tornar o Mach ampla-
mente disponível e operável entre sistemas de computação de
vários fornecedores
Os projetistas do Mach têm sido muito influenciados pelo
BSD (e pelo UNIX, em geral), cujos benefícios incluem:
• Uma interface de programador simples, com um bom
conjunto de primitivas e um conjunto consistente de inter-
faces aos recursos do sistema
B.3 Componentes do Sistema
Para atingir os objetivos de projeto do Mach, os desenvolvedores
reduziram a funcionalidade do sistema operacional a um pequeno
conjunto de abstrações básicas, a partir das quais todas as outras
funcionalidades podem ser derivadas. A abordagem do Mach é
colocar o mínimo possível dentro do kernel, mas tornando o
O Sistema Mach  2 9
o Mach 2.5 como base para seu novo sistema operacional, o
OSF/1. O lançamento do OSF/1 ocorreu um ano depois e,
agora, ele compete com o UNIX System V, Release 4, o sistema
operacional preferido entre os membros da UNIX Internatio-
nal (UI). Os membros da OSF incluem importantes empresas
de tecnologia como a IBM, a DEC e a HP. O Mach 2.5 também
é a base do sistema operacional da estação de trabalho NeXT,
criação de Steve Jobs, famoso pelos computadores da Apple. A
OSF está avaliando o Mach 3 como base de um futuro release
de sistema operacional e a pesquisa sobre o Mach continua na
CMU, na OSF e em outros locais.
• Fácil portabilidade para uma ampla classe de uniprocessa-
dores
• Uma extensa biblioteca de utilitários e aplicações
• Capacidade de combinar utilitários facilmente por meio de
pipes
É claro que os projetistas também queriam dar nova roupa-
gem ao que consideravam as desvantagens do BSD:
• Um kernel que se tornou repositório de muitos recursos
redundantes – e que, consequentemente, é difícil de geren-
ciar e modificar
• Objetivos originais de projeto que tornavam difícil dar
suporte a multiprocessadores, sistemas distribuídos e biblio-
tecas de programas compartilhadas – por exemplo, já que o
kernel foi projetado para uniprocessadores, não tem recursos
para trancamento (locking) de código ou dados que outros
processadores possam estar usando.
• Excessivas abstrações básicas, fornecendo muitos meios alter-
nativos semelhantes para a execução da mesma tarefa
O desenvolvimento do Mach continua sendo um empre-
endimento de porte. Os benefícios de um sistema assim são
igualmente grandes, no entanto. O sistema operacional é
executado em muitas arquiteturas uni e multiprocessadoras
existentes e pode ser facilmente portado para futuras arqui-
teturas. Ele torna a pesquisa mais fácil porque os cientistas
da computação podem adicionar recursos por intermédio de
código de nível de usuário, em vez de ter de escrever seu pró-
prio sistema operacional personalizado. As áreas de experi-
mentação incluem sistemas operacionais, bancos de dados,
sistemas distribuídos confiáveis, linguagens de multiproces-
samento, segurança e inteligência artificial distribuída. Em
sua versão corrente, o sistema Mach costuma ser tão eficiente
quanto outras versões importantes do UNIX ao executar tare-
fas semelhantes.
que estiver aí suficientemente poderoso para que todos os outros
recursos possam ser implementados em nível de usuário.
A filosofia de projeto do Mach é possuir um kernel sim-
ples e extensível, concentrado em recursos de comunicação.
Por exemplo, todas as solicitações ao kernel e toda a movi-
3 0   Apêndice B
mentação de dados entre processos são manipuladas através
de um mecanismo de comunicação. Portanto, o Mach pode
fornecer proteção a seus usuários no âmbito de todo o sis-
tema, protegendo o mecanismo de comunicação. A otimiza-
ção desse caminho único de comunicação pode resultar em
ganhos de desempenho significativos e é mais simples do que
tentar otimizar vários caminhos. O Mach é extensível por-
que muitas funções, tradicionalmente baseadas no kernel,
podem ser implementadas como servidores de nível de usuá-
rio. Por exemplo, todos os paginadores (inclusive o paginador
default) podem ser implementados externamente e chamadas
pelo kernel para o usuário.
O Mach é um exemplo de sistema orientado a objetos em que
os dados e as operações que manipulam esses dados são encap-
sulados em um objeto abstrato. Apenas as operações do objeto
podem atuar sobre as entidades nele definidas. Os detalhes de
como essas operações são implementadas ficam ocultos, assim
como as estruturas de dados internas. Logo, um programador só
pode usar um objeto invocando suas operações exportadas defi-
nidas. O programador pode alterar as operações internas sem
mudar a definição da interface e, portanto, as modificações e oti-
mizações não afetam outros aspectos da operação do sistema.
A abordagem orientada a objetos suportada pelo Mach permite
que os objetos residam em qualquer local, em uma rede de sis-
temas Mach, de forma transparente ao usuário. O mecanismo
port, discutido mais tarde nesta seção, torna tudo isso possível.
As abstrações primitivas do Mach são o coração do sistema
e são as seguintes:
• Uma tarefa é um ambiente de execução que fornece a uni-
dade básica de alocação de recursos. Ela é composta por um
espaço de endereçamento virtual e acesso protegido a recur-
sos do sistema, por meio de portas, e pode conter um ou mais
threads.
• Um thread é a unidade básica de execução e deve ser exe-
cutado no contexto de uma tarefa (que fornece o espaço de
endereçamento). Todos os threads de uma tarefa compar-
tilham os recursos da tarefa (portas, memória etc). Não existe
a noção de processo no Mach. Em vez disso, um processo tra-
dicional seria implementado como uma tarefa com um único
thread de controle.
• Uma porta é o mecanismo básico de referência a objetos no
Mach e é implementada como um canal de comunicação pro-
tegido pelo kernel. A comunicação é executada pelo envio de
mensagens para portas; as mensagens são enfileiradas na porta
de destino quando não há um thread pronto para recebê-las. As
portas são protegidas por recursos gerenciados pelo kernel ou
direitos de portas; uma tarefa deve ter um direito de porta para
enviar uma mensagem a uma porta. O programador invoca
uma operação em um objeto enviando uma mensagem a uma
porta associada a esse objeto. O objeto que está sendo represen-
tado por uma porta recebe as mensagens.
• Um conjunto de portas é um grupo de portas que compar-
tilham uma fila de mensagens comum. Um thread pode rece-
ber mensagens de um conjunto de portas e, portanto, atender
várias portas. Cada mensagem recebida identifica a porta
individual (do conjunto) a partir da qual ela foi recebida; o
receptor pode usar essa informação para identificar o objeto
referenciado pela mensagem.
• Uma mensagem é o método básico de comunicação entre
threads no Mach. Ela é um conjunto tipificado de objetos de
dados; para cada objeto, ela pode conter os dados reais ou um
ponteiro para dados out-of-line1. Os direitos de porta são pas-
sados em mensagens; essa é a única maneira de movimentá-los
entre tarefas. (A passagem de um direito de porta em memória
compartilhada não funciona porque o kernel do Mach não per-
mitirá que a nova tarefa use um direito obtido desta forma.)
• Um objeto memória é uma fonte de memória; as tarefas
podem acessá-lo mapeando partes de um objeto (ou o objeto
inteiro) para seus espaços de endereçamento. O objeto pode
ser gerenciado por um gerenciador de memória externo de
modalidade de usuário. Um exemplo é um arquivo gerenciado
por um servidor de arquivos; no entanto, um objeto memória
pode ser qualquer objeto para o qual o acesso mapeado na
memória faça sentido. Uma implementação mapeada em buf-
fer de um pipe UNIX é um exemplo.
A Figura B.2 ilustra essas abstrações que aprofundamos no
restante deste capítulo.
Uma característica não usual do Mach, essencial para a efi-
ciência do sistema, é a combinação de recursos de memória e
de comunicação entre processos (IPC). Enquanto outros sis-
temas distribuídos (como o Solaris, com seus recursos NFS)
têm extensões de uso específico para o sistema de arquivos, de
modo a estendê-lo por toda uma rede, o Mach fornece uma
fusão de memória e mensagens, extensível e de uso geral, no
coração do seu kernel. Esse recurso não só permite que o Mach
seja usado para programação distribuída e paralela, mas tam-
bém ajuda na implementação do próprio kernel.
O Mach conecta gerenciamento de memória e IPC permi-
tindo que um seja usado na implementação do outro. A base
do gerenciamento de memória é o uso de objetos memória.
Um objeto memória é representado por uma porta (ou por-
tas) e mensagens de IPC são enviadas a essa porta para solici-
tar operações (por exemplo, pagein, pageout) no objeto. Já
que a IPC é usada, os objetos memória podem residir em sis-
temas remotos e serem acessados de maneira transparente. O
kernel armazena em cache local o conteúdo de objetos memó-
ria. Inversamente, técnicas de gerenciamento de memória são
usadas na implementação de transmissão de mensagens. Onde
possível, o Mach transmite mensagens movendo ponteiros
para objetos memória compartilhados, e não pela cópia dos
próprios objetos.
A IPC tende a causar overhead considerável no sistema; para
mensagens dentro do sistema, ela é, em geral, menos eficiente do
que a comunicação executada por meio de memória comparti-
lhada. Já que o Mach é um kernel fundamentado em mensagens,
a manipulação de mensagens deve ser executada eficientemente.
Grande parte da ineficiência na manipulação de mensagens,
em sistemas operacionais tradicionais, deve-se tanto à cópia de
mensagens de uma tarefa para outra (para mensagens dentro
1
Dados contidos diretamente na mensagem chamam-se dados in-line; se a mensa-
gem contém ponteiros para os dados reais, os dados são chamados dados out-of-line.
(N.R.T.)

região de texto
threads
contador de
programa
tarefa
região de dados
Figura B.2 Abstrações básicas do Mach.
do computador) como à baixa velocidade de transferência na
rede (para mensagens entre computadores). Para resolver esses
problemas, o Mach usa o remapeamento de memória virtual
para transferir o conteúdo de mensagens grandes. Em outras
palavras, a transferência de mensagens modifica o espaço de
endereçamento da tarefa receptora para incluir uma cópia do
conteúdo da mensagem. Técnicas de cópia virtual (ou cópia
após gravação) são usadas para evitar ou retardar a cópia real
dos dados. Essa abordagem tem diversas vantagens:
• Aumento da flexibilidade no gerenciamento de memória para
programas de usuário
• Maior generalidade, permitindo que a abordagem de cópia
virtual seja usada em computadores forte ou fracamente
acoplados
B.4 Gerenciamento de Processos
Uma tarefa pode ser considerada como um processo tradicio-
nal que não tem um ponteiro de instruções ou um conjunto
de registradores. Ela contém um espaço de endereçamento
virtual, um conjunto de direitos de porta e informações de
contabilidade. A tarefa é uma entidade passiva que não faz
coisa alguma, a menos que tenha um ou mais threads em exe-
cução nela.
B.4.1 Estrutura Básica
Uma tarefa contendo um thread é semelhante a um processo
no UNIX. Da mesma forma que uma chamada de sistema
fork produz um novo processo no UNIX, o Mach cria uma
nova tarefa para emular esse comportamento. A memória da
nova tarefa é uma duplicata do espaço de endereçamento do
pai, como imposto pelos atributos de herança da memória do
pai. A nova tarefa contém um thread que é iniciado no mesmo
O Sistema Mach  3 1
mensagem
porta
conjunto de portas
objeto memória secundária
memória
• Melhor desempenho em comparação com a transmissão de
mensagens do UNIX
• Migração de tarefas mais fácil (já que as portas são inde-
pendentes de localização, uma tarefa e todas as suas por-
tas podem ser transferidas de um computador para outro;
todas as tarefas que se comunicaram anteriormente com
a tarefa transferida podem continuar fazendo isso porque
elas só referenciam a tarefa por suas portas e se comuni-
cam por meio de mensagens para essas portas)
Nas seções a seguir, detalhamos a operação de gerencia-
mento de processos, da IPC e do gerenciamento de memó-
ria. Depois, discutimos a habilidade camaleônica do Mach de
suportar interfaces múltiplas de sistemas operacionais.
ponto da chamada de criação fork, no pai. Threads e tarefas
também podem ser suspensos e retomados.
Os threads são especialmente úteis em aplicações de ser-
vidor, comuns no UNIX, já que uma tarefa pode ter múlti-
plos threads para atender múltiplas solicitações feitas a ela.
Os threads também permitem o uso eficiente de recursos de
computação paralela. Em vez de haver um processo em cada
processador, com a correspondente perda de desempenho e
overhead imposto ao sistema operacional, uma tarefa pode ter
seus threads espalhados entre processadores paralelos. Além
disso, os threads adicionam eficiência a programas de nível
de usuário. Por exemplo, no UNIX, um processo inteiro deve
esperar quando ocorre um erro de página ou quando uma cha-
mada de sistema é executada. Em uma tarefa com múltiplos
threads, só o thread que causa o erro de página ou executa uma
chamada de sistema é adiado; todos os outros threads conti-
3 2   Apêndice B
nuam em execução. Já que o Mach tem threads suportados pelo
kernel (Capítulo 4), esses threads implicam algum custo asso-
ciado. Eles exigem estruturas de dados de suporte no kernel e
o kernel deve fornecer algoritmos de scheduling mais comple-
xos. Esses algoritmos e estados dos threads são discutidos no
Capítulo 4.
No nível do usuário, os threads podem estar em um de dois
estados:
• Em execução: O thread está em execução ou esperando a
alocação de um processador. Um thread é considerado em
execução mesmo quando está bloqueado dentro do ker-
nel (esperando que um erro de página seja manipulado, por
exemplo).
• Suspenso: O thread não está em execução em um processa-
dor nem esperando pela alocação de um processador. Um
thread só pode retomar sua execução quando volta ao estado
“em execução”.
Esses dois estados também estão associados a uma tarefa.
Uma operação em uma tarefa afeta todos os threads da tarefa
e, portanto, a suspensão de uma tarefa envolve a suspensão de
todos os seus threads. No entanto, a suspensão de tarefas e a
suspensão de threads são mecanismos independentes e separa-
dos e, assim, a retomada de um thread em uma tarefa suspensa
não retoma a tarefa.
O Mach fornece primitivas a partir das quais ferramentas de
sincronização de threads podem ser construídas. Essa prática
é consistente com a filosofia do Mach de fornecer funcionali-
dade mínima, porém suficiente, no kernel. O recurso de IPC do
Mach pode ser usado na sincronização, com processos (tarefas)
trocando mensagens em pontos de encontro. A sincronização
no nível dos threads é fornecida por chamadas que iniciam e
interrompem os threads nos momentos apropriados. Uma con-
tagem de suspensos é mantida para cada thread. Esta contagem
permite que várias chamadas suspend sejam executadas em
um thread e só quando ocorre um número igual de chamadas
resume é que o thread é retomado. Infelizmente, esse recurso
tem suas limitações. Já que é um erro uma chamada start ser
executada antes de uma chamada stop (a contagem de suspen-
sos ficaria negativa), essas rotinas não podem ser usadas para
sincronizar o acesso a dados compartilhados. No entanto, as
operações wait e signal, associadas aos semáforos e usadas
para sincronização, podem ser implementadas por intermédio
das chamadas IPC. Discutimos esse método na Seção B.5.
B.4.2 O Pacote de Threads C
O Mach fornece rotinas de baixo nível, porém flexíveis, em
vez de funções refinadas, grandes e mais restritivas. Em vez
de fazer os programadores trabalharem nesse baixo nível, o
Mach fornece interfaces de nível mais alto para a programa-
ção em C e outras linguagens. Por exemplo, o pacote de threads
C fornece vários threads de controle, variáveis compartilha-
das, exclusão mútua para seções críticas e variáveis de condi-
ção para sincronização. Na verdade, os threads C são uma das
maiores influências do padrão Pthreads do POSIX e muitos
sistemas operacionais estão sendo modificados para suportar
esse padrão. Como resultado, há fortes semelhanças entre os
threads C e as interfaces de programação do Pthreads. As roti-
nas de controle de threads incluem chamadas para a execução
dessas tarefas:
• Criar um novo thread dentro de uma tarefa, dados uma fun-
ção a ser executada e parâmetros como entrada. O thread é,
então, executado concorrentemente com o thread criador que
recebe um identificador de thread quando a chamada retorna.
• Destruir o thread chamador e retornar um valor para o thread
criador.
• Esperar que um thread específico termine antes de permitir
que o thread chamador continue. Essa chamada é uma fer-
ramenta de sincronização, muito semelhante às chamadas de
sistema wait do UNIX.
• Conceder o uso de um processador, sinalizando que o schedu-
ler pode executar outro thread nesse momento. Essa chamada
também é útil em presença de um scheduler preemptivo, já
que pode ser usada para abandonar voluntariamente a CPU
antes de o quantum de tempo (ou intervalo de scheduling)
expirar quando um thread não mais precisa da CPU.
A exclusão mútua é obtida por meio do uso de spinlocks,
como discutido no Capítulo 6. As rotinas associadas à exclusão
mútua são as seguintes:
• A rotina mutex_alloc cria dinamicamente uma variável
mutex.
• A rotina mutex_free desaloca uma variável mutex criada
dinamicamente.
• A rotina mutex_lock tranca (impõe um lock) uma variável
mutex. O thread em execução entra em loop em um spin-
lock até que o lock seja obtido. Isso resulta em deadlock se um
thread com um lock tenta trancar a mesma variável mutex. A
espera limitada não é garantida pelo pacote de threads C. Em
vez disso, ela depende das instruções de hardware usadas na
implementação das rotinas mutex.
• A rotina mutex_unlock destranca uma variável mutex,
muito parecido com o estilo da operação signal típica de
um semáforo.
A sincronização geral sem espera em ação pode ser obtida
com o uso de variáveis de condição que podem ser usadas
para implementar uma região crítica condicional (ou moni-
tor), como descrito no Capítulo 6. Uma variável de condição
é associada a uma variável mutex e reflete um estado booleano
dessa variável. As rotinas associadas à sincronização geral são
as seguintes:
• A rotina condition_alloc aloca dinamicamente uma
variável de condição.
• A rotina condition_free exclui uma variável de condi-
ção criada dinamicamente alocada como resultado de
condition_alloc.
• A rotina condition_wait destranca (desativa o lock)
a variável mutex associada e bloqueia o thread até que uma
rotina condition_signal seja executada na variável
de condição, indicando que o evento que estava sendo espe-

rado pode ter ocorrido. A variável mutex é, então, trancada e
o thread continua. Uma rotina condition_signal não
garante a permanência da condição até que o thread desblo-
queado finalmente retorne de sua chamada condition_
wait e, assim, o thread despertado deve entrar em loop,
executando a rotina condition_wait até que seja desblo-
queado e a condição permaneça.
Como exemplo das rotinas de threads C, considere o pro-
blema de sincronização do buffer limitado da Seção 6.6.1. O
produtor e o consumidor são representados como threads que
acessam o pool comum de buffers limitados. Usamos uma
variável mutex para proteger o buffer enquanto ele está sendo
atualizado. Uma vez que tenhamos acesso exclusivo ao buffer,
usamos variáveis de condição para bloquear o thread pro-
dutor se o buffer estiver cheio e para bloquear o thread con-
sumidor se o buffer estiver vazio. Embora esse programa
normalmente fosse escrito na linguagem C, em um sistema
Mach, usaremos a sintaxe familiar ao estilo Pascal, dos capí-
tulos anteriores, a título de clareza. Como no Capítulo 6, esta-
mos supondo que o buffer seja composto por n posições,
cada um podendo conter um item. O semáforo mutex for-
nece exclusão mútua para acessos ao pool de buffers e é ini-
cializado com o valor 1. Os semáforos empty e full contam o
número de buffers vazios e cheios, respectivamente. O semá-
foro empty é inicializado com o valor n; o semáforo full é ini-
cializado com o valor 0. A variável de condição nonempty é
verdadeira enquanto o buffer possuir itens e nonfull é verda-
deira se o buffer possuir uma posição vazia.
O primeiro passo inclui a alocação das variáveis mutex e de
condição:
mutex_alloc(mutex); condition_alloc(nonempty, nonfull);
O código do thread produtor é mostrado na Figura B.3 e o
código do thread consumidor, na Figura B.4. Quando o pro-
grama termina, as variáveis mutex e de condição têm de ser
desalocadas:
mutex_free(mutex); condition_free(nonempty, nonfull);
Figura B.3 A estrutura do processo produtor.
O Sistema Mach  3 3
B.4.3 O Scheduler da CPU
O scheduler da CPU para um sistema operacional multiproces-
sador baseado em threads é mais complexo do que seus equi-
valentes baseados em processos. Geralmente, há mais threads
em um sistema multithreads do que processos em um sistema
multitarefas. Controlar vários processadores também é difí-
cil e é uma área de pesquisa relativamente nova. O Mach usa
uma política simples para manter o scheduler gerenciável. Ape-
nas threads são incluídos no schedule e, portanto, nenhum
conhecimento das tarefas é necessário ao scheduler. Todos
os threads competem igualmente por recursos, inclusive por
quanta de tempo.
Cada thread tem um número de prioridade associado que
varia de 0 a 127 e sua base é a média exponencial do uso da
CPU pelo thread. Isto é, um thread que usou recentemente
a CPU, por um período longo, tem a prioridade mais baixa.
O Mach usa a prioridade para inserir o thread em uma das
32 filas de execução globais. Essas filas são pesquisadas por
ordem de prioridade, em busca de threads em espera, quando
um processador se torna ocioso. O Mach também mantém
filas de execução por processador ou filas locais. Uma fila de
execução local é usada para threads limitados a um processa-
dor individual. Por exemplo, um driver de dispositivo de um
dispositivo conectado a uma CPU individual só deve ser exe-
cutado nessa CPU.
Em vez de um despachante central que atribua threads
a processadores, cada processador consulta as filas de exe-
cução local e global para selecionar o próximo thread apro-
priado para execução. Os threads da fila de execução local
têm prioridade absoluta sobre os das filas globais porque
assume-se que eles estejam executando alguma tarefa para
o kernel. As filas de execução – como a maioria de outros
objetos no Mach – são trancadas ao serem modificadas para
que não ocorram alterações simultâneas feitas por múltiplos
processadores. Para acelerar o despacho de threads na fila
de execução global, o Mach mantém uma lista de processa-
dores ociosos.
Figura B.4 A estrutura do processo consumidor.
3 4   Apêndice B
A natureza multiprocessadora do Mach causa dificulda-
des adicionais de scheduling. Um quantum de tempo fixo não
é apropriado porque, por exemplo, pode haver menos threads
executáveis do que processadores disponíveis. Seria um des-
perdício interromper um thread, com uma mudança de con-
texto para o kernel, quando seu quantum expira, apenas para
que ele seja retornado ao estado de execução. Portanto, em vez
de usar um quantum de tamanho fixo, o Mach varia o tama-
nho do quantum de tempo inversamente ao número total
de threads no sistema. No entanto, ele mantém o quantum de
tempo constante no sistema inteiro. Por exemplo, em um
sistema com 10 processadores, 11 threads e um quantum de
100 milissegundos, uma mudança de contexto somente precisa
ocorrer a cada segundo, em cada processador, para manter o
quantum desejado.
É claro que ainda existem complicações. Até mesmo o
abandono da CPU enquanto há a espera por um recurso, é
mais difícil do que em sistemas operacionais tradicionais. Pri-
meiro, um thread deve emitir uma chamada para alertar o
scheduler de que está para ser bloqueado. Esse alerta evita
condições de concorrência e deadlocks que poderiam ocor-
rer em caso de execução em um ambiente multiprocessa-
dor. Uma segunda chamada causa realmente a remoção do
thread da fila de execução até que o evento apropriado ocorra.
O scheduler usa muitos outros estados internos dos threads
para controlar a execução de threads.
B.4.4 Manipulação de Exceções
O Mach foi projetado para fornecer um único sistema de mani-
pulação de exceções simples e consistente, com suporte para
exceções – padrão assim como para exceções definidas pelo
usuário. Para evitar redundância no kernel, ele usa primitivas
do kernel sempre que possível. Por exemplo, um manipulador
de exceções é apenas outro thread da tarefa em que a exce-
ção ocorre. Mensagens de chamadas de procedimento remo-
tas (RPC) são usadas para sincronizar a execução do thread
que causou a exceção (o alvo) com a execução do manipulador
e para transmitir informações sobre a exceção, entre o alvo e o
manipulador. As exceções do Mach também são usadas para
emular o pacote signal do BSD.
As paralisações da execução normal de um programa
ocorrem de duas maneiras: exceções geradas internamente e
interrupções externas. Interrupções são paralisações geradas
assincronamente em um thread ou tarefa, enquanto exceções
são causadas pela ocorrência de condições incomuns durante
a execução de um thread. O recurso de exceção de uso geral
do Mach é usado para suporte à detecção de erros e ao depu-
rador. Esse recurso também é útil para outras funções, como
obter o dump (despejo) de memória de uma tarefa inválida,
permitindo que as tarefas manipulem seus próprios erros (em
sua maioria, aritméticos), e emular instruções não implemen-
tadas em hardware.
O Mach dá suporte a dois níveis de granularidade diferen-
tes para a manipulação de exceções A manipulação de erros é
suportada pela manipulação de exceções por thread, enquanto
os depuradores usam a manipulação por tarefa. Faz pouco sen-
tido tentar depurar apenas um thread ou gerar exceções, a par-
tir de threads múltiplos, que invoquem depuradores múltiplos.
Além dessa distinção, a única diferença entre os dois tipos de
exceções reside em sua herança a partir de uma tarefa pai. Os
recursos de manipulação de exceções no âmbito de uma tarefa
são passados da tarefa pai às tarefas filhas e, portanto, os depu-
radores podem manipular uma árvore inteira de tarefas. Os
manipuladores de erros não são herdados e não tem um mani-
pulador default em tempo de criação de threads e tarefas. Para
concluir, os manipuladores de erros têm precedência sobre os
depuradores quando as exceções ocorrem simultaneamente.
Essa abordagem é usada porque os manipuladores de erros
costumam fazer parte da tarefa e, portanto, devem ser executa-
dos normalmente mesmo na presença de um depurador.
A manipulação de exceções ocorre da seguinte forma:
• O thread-alvo gera a notificação de uma ocorrência de exce-
ção por intermédio de uma mensagem RPC raise enviada
para o manipulador.
• O alvo chama, então, uma rotina para esperar até que a exce-
ção seja manipulada.
• O manipulador recebe a notificação da exceção que inclui,
usualmente, informações sobre a exceção, o thread e a tarefa
que causou a exceção.
• O manipulador executa sua função de acordo com o tipo da
exceção. A ação do manipulador envolve a derrubada da exce-
ção o que causa a retomada ou o encerramento do thread-alvo.
Para dar suporte à execução de programas BSD, o Mach
tem de suportar sinais no estilo BSD. Os sinais fornecem inter-
rupções e exceções geradas por software. Infelizmente, sinais
têm funcionalidade limitada em sistemas operacionais multi-
threads. O primeiro problema é que, no UNIX, um manipu-
lador de sinais deve ser uma rotina do processo que recebe o
sinal. Se o sinal for causado por um problema no próprio pro-
cesso (por exemplo, uma divisão por zero), o problema não
pode ser remediado porque um processo tem acesso limitado
ao seu próprio contexto. Um segundo aspecto mais complicado
dos sinais é que eles foram projetados apenas para programas
com um único thread. Por exemplo, não faz sentido que todos
os threads de uma tarefa obtenham um sinal, mas como um
sinal pode ser visto por apenas um thread?
Já que o sistema de sinais deve funcionar corretamente com
aplicações multithreads para que o Mach execute programas
4.3 BSD, os sinais não podiam ser abandonados. No entanto,
o código teve de ser reescrito várias vezes para produzir um
pacote de sinais funcionalmente correto! Um último problema
dos sinais do UNIX é que eles podem ser perdidos. Essa perda
acontece quando outro sinal do mesmo tipo ocorre antes de o
primeiro ser manipulado. As exceções do Mach são enfileira-
das como resultado de sua implementação de RPCs.
Sinais gerados externamente, inclusive os enviados de um
processo BSD para outro, são processados pela seção de servi-
dor BSD do kernel do Mach 2.5. Portanto, seu comportamento
é o mesmo que ocorre sob o BSD. Exceções de hardware cons-
tituem uma questão diferente porque os programas BSD espe-
ram receber exceções de hardware como sinais. Logo, uma

exceção de hardware causada por um thread deve chegar ao
thread como um sinal. Para que esse resultado seja produzido,
as exceções de hardware são convertidas em RPCs de exceções.
Para tarefas e threads que não fazem uso explícito do recurso
de manipulação de exceções do Mach, o destino das RPCs de
exceções é uma tarefa default interna ao kernel. Essa tarefa tem
apenas uma finalidade: seu thread é executado em um loop
contínuo, recebendo as RPCs de exceções. Para cada RPC, ela
converte a exceção no sinal apropriado que é enviado ao thread
causador da exceção de hardware. Ela, então, conclui a RPC
B.5 Comunicação entre Processos
A maioria dos sistemas operacionais comerciais, como o UNIX,
fornece comunicação entre processos e entre hosts, com nomes
globais fixos (ou endereços de Internet). Não há independên-
cia de localização de recursos porque qualquer sistema remoto
que precise usar um recurso, deve saber o nome do sistema que
fornece esse recurso. Geralmente, dados em mensagens são
fluxos de bytes não tipificados. O Mach simplifica esse cená-
rio enviando mensagens entre portas independentes de loca-
lização. As mensagens contêm dados tipificados para facilitar
a interpretação. Todos os métodos de comunicação do BSD
podem ser implementados com esse sistema simplificado.
Os dois componentes de IPC do Mach são as portas e as
mensagens. Quase tudo no Mach é um objeto e todos os obje-
tos são endereçados através de suas portas de comunicação.
Mensagens são enviadas a essas portas para iniciar operações
nos objetos pelas rotinas que implementam os objetos. Ao
depender somente de portas e mensagens para toda a comuni-
cação, o Mach fornece independência de localização aos obje-
tos e segurança na comunicação. A independência de dados é
fornecida pela tarefa NetMsgServer (Seção B.5.3).
O Mach garante a segurança requerendo que os emisso-
res e receptores de mensagens tenham direitos. Um direito
consiste de um nome de porta e uma competência – enviar
ou receber – nessa porta e se parece muito com uma com-
petência nos sistemas orientados a objetos. Apenas uma
tarefa pode ter direitos de recebimento em uma determi-
nada porta, mas muitas tarefas podem ter direitos de envio.
Quando um objeto é criado, seu criador também aloca uma
porta para representar o objeto e obtém os direitos de acesso
dessa porta. Direitos podem ser concedidos pelo criador do
objeto, inclusive o kernel, e são passados em mensagens. Se o
detentor de um direito de recebimento envia esse direito em
uma mensagem, o receptor da mensagem obtém o direito e o
emissor o perde. Uma tarefa pode alocar portas para permi-
tir o acesso a qualquer objeto que possua ou para comuni-
cação. A destruição de uma porta ou do detentor do direito
de recebimento causa a revogação de todos os direitos dessa
porta e as tarefas que detêm direitos de envio podem ser
notificadas, se desejado.
B.5.1 Portas
Uma porta é implementada como uma fila limitada e prote-
gida, dentro do kernel do sistema em que o objeto reside. Se
uma fila estiver cheia, o emissor pode abortar o envio, esperar
O Sistema Mach  3 5
derrubando a condição de exceção original. Com a conclusão
da RPC, o thread iniciador reentra em estado de execução. Ele
vê imediatamente o sinal e executa seu código de manipulação
de sinais. Dessa forma, todas as exceções de hardware come-
çam de maneira uniforme – como RPCs de exceções. Threads
não projetados para manipular essas exceções, no entanto, as
recebem como ocorreria em um sistema BSD – padrão – como
sinais. No Mach 3.0, o código de manipulação de sinais é trans-
ferido inteiramente para um servidor, mas a estrutura geral e o
fluxo de controle são semelhantes aos do Mach 2.5.
que fique disponível uma locação na fila ou deixar que o kernel
distribua a mensagem em lugar da porta.
Várias chamadas de sistema fornecem as seguintes funcio-
nalidades para a porta:
• Alocar uma nova porta em uma tarefa especificada e fornecer,
à tarefa do chamador, todos os direitos de acesso à nova porta.
O nome da porta é retornado.
• Desalocar os direitos de acesso de uma tarefa para uma porta.
Se a tarefa tiver o direito de recebimento, a porta é destruída
e todas as outras tarefas com direitos de envio são, potencial-
mente, notificadas.
• Obter o status corrente da porta de uma tarefa.
• Criar uma porta reserva à qual é fornecido o direito de recebi-
mento de uma porta se a tarefa com o direito de recebimento
solicitar sua desalocação ou for encerrada.
Quando uma tarefa é criada, o kernel gera várias portas
para ela. A função task_self retorna o nome da porta que
representa a tarefa em chamadas ao kernel. Por exemplo, para
uma tarefa alocar uma nova porta, ela chamaria port_allo-
cate com task_self como o nome da tarefa que possuirá
a porta. A criação de threads resulta em uma porta thread_
self semelhante para threads no kernel. Esse esquema é pare-
cido com o conceito-padrão de ID de processo encontrado no
UNIX. Outra porta criada para uma tarefa é retornada por
task_notify e é a porta para a qual o kernel enviará mensa-
gens de notificação de eventos (como as notificações de encer-
ramento de portas).
As portas também podem ser reunidas em conjuntos de
portas. Esse recurso é útil quando um thread precisa atender às
solicitações que chegam em várias portas – por exemplo, para
vários objetos. Uma porta não pode ser membro de mais de um
conjunto de portas de cada vez; e, se uma porta estiver em um
conjunto, pode não ser usada diretamente para receber men-
sagens. Em vez disso, as mensagens serão roteadas para a fila
do conjunto de portas. Um conjunto de portas não pode rece-
ber mensagens, diferente da porta. Os conjuntos de portas são
objetos que servem a uma finalidade semelhante a da chamada
de sistema select do 4.3 BSD, mas são mais eficientes.
B.5.2 Mensagens
Uma mensagem é composta por um cabeçalho de tamanho
fixo e um número variável de objetos de dados tipificados. O
cabeçalho contém o nome da porta de destino, o nome da porta
3 6   Apêndice B

porta

fila de mensagens mensagem mensagem

porta de destino
porta de resposta
tamanho/operação
dados tipificados puros
porta
direitos de porta
dados out-of-line

controle de mensagens

objeto cache de memória objeto cache de memória

Figura B.5 Mensagens no Mach.

de resposta para a qual mensagens de retorno devem ser envia-
das e o tamanho da mensagem (Figura B.5). Os dados na men-
sagem (ou dados in-line) ficavam limitados a menos de 8 KB
em sistemas Mach 2.5, mas o Mach 3.0 não tem limites. Quais-
quer dados que excedam esse limite devem ser enviados em
várias mensagens ou, o que é mais provável, podem ser referen-
ciados por um ponteiro em uma mensagem (ou dados out-of-
line). Cada seção de dados pode conter dados de tipo simples
(números ou caracteres), direitos de porta ou ponteiros para
dados out-of-line. Cada seção tem um tipo associado para que
o receptor possa descompactar os dados corretamente mesmo
se usar uma ordenação de bytes diferente da usada pelo emis-
sor. O kernel também inspeciona a mensagem em busca de
certos tipos de dados. Por exemplo, o kernel deve processar as
informações de porta de uma mensagem, traduzindo o nome
da porta para um endereço interno da estrutura de dados da
porta ou encaminhando-as, para processamento, a NetMsgSer-
ver (Seção B.5.3).
O uso de ponteiros em uma mensagem fornece o meio
de transferência do espaço de endereçamento inteiro de uma
tarefa em uma única mensagem. O kernel também deve pro-
cessar ponteiros para dados out-of-line, já que um ponteiro
para dados no espaço de endereçamento do emissor seria invá-
lido no do receptor – principalmente, se o emissor e o recep-
tor residirem em sistemas diferentes! Geralmente, os sistemas
enviam mensagens copiando os dados do emissor para o recep-
tor. Já que essa técnica pode ser ineficiente, principalmente
em caso de mensagens grandes, o Mach otimiza este procedi-
mento. Os dados referenciados por um ponteiro em uma men-
sagem sendo enviada a uma porta no mesmo sistema, não são
copiados entre o emissor e o receptor. Em vez disso, o mapa de
endereços da tarefa receptora é modificado para incluir uma
cópia do tipo cópia após gravação das páginas da mensagem.
Essa operação é muito mais rápida do que uma cópia de dados
e torna a transmissão de mensagens eficiente. Em essência, a
transmissão de mensagens é implementada por meio do geren-
ciamento de memória virtual.
Na versão 2.5, essa operação era implementada em duas
fases. O ponteiro para uma região de memória fazia o ker-
nel mapear essa região de memória para seu próprio espaço,
temporariamente, definindo o mapa de memória do emissor
como da modalidade de cópia após gravação para assegurar
que nenhuma modificação afetasse a versão original dos dados.
Quando uma mensagem era recebida em seu destino, o ker-
nel movia seu mapeamento para o espaço de endereçamento
do receptor, usando uma região de memória virtual recém-alo-
cada dentro dessa tarefa.
Na versão 3, esse processo foi simplificado. O kernel cria
uma estrutura de dados que seria uma cópia da região se fizesse
parte de um mapa de endereços. No recebimento, essa estru-
tura de dados é adicionada ao mapa do receptor e se torna uma
cópia acessível a este receptor.
As regiões recém-alocadas em uma tarefa não precisam
ser contíguas a alocações anteriores e, portanto, diz-se que a
memória virtual do Mach é esparsa, composta por regiões de
dados separadas por endereços não alocados. Uma transferên-
cia completa de mensagem é mostrada na Figura B.6.
B.5.3 O NetMsgServer
Para uma mensagem ser enviada entre computadores, seu des-
tino deve ser localizado e a mensagem deve ser transmitida ao
destino. Tradicionalmente, o UNIX deixa esses mecanismos a
cargo dos protocolos de rede de baixo nível que requerem o uso
de extremidades de comunicação atribuídas estaticamente (por
exemplo, o número de porta para serviços baseados em TCP ou
UDP). Um dos princípios do Mach é que todos os objetos no
sistema sejam independentes de localização e que a localização
seja transparente ao usuário. Este princípio requer que o Mach
forneça nomeação e transporte transparentes com referência à
localização, para estender a IPC por vários computadores.

mapa mapa de mapa
de A kernel de B
operação de envio
Figura B.6 Transferência de mensagens no Mach.
Esta nomeação e este transporte são executados pelo
Network Message Server (NetMsgServer), um daemon de
conexão de rede de nível de usuário, baseado em competên-
cias, que encaminha mensagens entre hosts. Ele também for-
nece um serviço de nomes primitivo, abrangente a toda a rede,
que permite às tarefas registrarem portas para buscas a serem
realizadas por tarefas em qualquer outro computador da rede.
As portas no Mach só podem ser transferidas em mensagens e
as mensagens devem ser enviadas a portas; o serviço de nomes
primitivo resolve o problema de transferir a primeira porta para
que tarefas em diferentes computadores troquem mensagens.
As interações subsequentes da IPC são totalmente transpa-
rentes; o NetMsgServer rastreia todos os direitos e a memó-
ria out-of-line passados em mensagens entre computadores e
providencia as transferências apropriadas. Os NetMsgServers
mantêm, entre eles próprios, um banco de dados distribuído de
direitos de porta transferidos entre computadores e das portas
às quais esses direitos correspondem.
O kernel usa o NetMsgServer quando uma mensagem tem
de ser enviada a uma porta que não está no computador do ker-
nel. A IPC do kernel do Mach é usada para transferir a men-
sagem ao NetMsgServer local. O NetMsgServer usa, então,
quaisquer protocolos de rede apropriados para transferir a
mensagem ao seu parceiro no outro computador; o conceito
de um NetMsgServer é independente de protocolo e foram
construídos NetMsgServers que usam vários protocolos. É
claro que os NetMsgServers envolvidos em uma transferência
devem estar de acordo quanto ao protocolo usado. Para con-
cluir, o NetMsgServer do computador de destino usa a IPC do
kernel deste computador para enviar a mensagem à tarefa de
destino correta.
O recurso de estender a IPC local, transparentemente pelos
nós, é suportado pelo uso de portas substitutas. Quando um
direito de envio é transferido de um computador para outro, o
NetMsgServer do computador de destino cria uma nova porta,
ou porta substituta, para representar a porta original no des-
tino. As mensagens enviadas a essa porta substituta são rece-
bidas pelo NetMsgServer e encaminhadas transparentemente
O Sistema Mach  3 7
mapa mapa de mapa
de A kernel de B
operação de recebimento
à porta original; esse procedimento é um exemplo de como os
NetMsgServers cooperam para tornar uma porta substituta
indistinguível da porta original.
Já que o Mach é projetado para funcionar em uma rede de
sistemas heterogêneos, ele deve fornecer um meio de enviar,
entre sistemas, dados formatados de uma forma que seja com-
preensível tanto para o emissor quanto para o receptor. Infeliz-
mente, os computadores diferem nos formatos que usam para
armazenar vários tipos de dados. Por exemplo, um inteiro em
um sistema pode ocupar 2 bytes para ser armazenado e o byte
mais significativo pode ser armazenado antes do menos signi-
ficativo. Outro sistema pode inverter esta ordem. Portanto, o
NetMsgServer usa a informação de tipo, armazenada em uma
mensagem, para converter os dados do formato do emissor
para o do receptor. Dessa forma, todos os dados são represen-
tados corretamente quando alcançam seu destino.
O NetMsgServer de um determinado computador aceita
RPCs que incluem e buscam portas de rede em seu serviço
de nomes, bem como as removem do seu serviço de nomes.
Como medida de segurança, um valor de porta fornecido em
uma solicitação de inclusão deve coincidir com o da solicitação
de remoção para que um thread possa requerer a remoção de
um nome de porta do banco de dados.
Como exemplo da operação do NetMsgServer, consi-
dere um thread no nó A enviando uma mensagem para uma
porta que está em uma tarefa no nó B. O programa simples-
mente envia uma mensagem a uma porta para a qual ele tenha
direito de envio. Primeiro, a mensagem é passada ao kernel que
a libera para seu primeiro receptor, o NetMsgServer do nó A.
O NetMsgServer contata, então, (por intermédio de suas infor-
mações do banco de dados) o NetMsgServer do nó B e envia a
mensagem. O NetMsgServer do nó B apresenta a mensagem ao
kernel com a porta local apropriada para o nó B. Para concluir,
o kernel fornece a mensagem para a tarefa receptora quando
um thread desta tarefa executa uma chamada msg_receive.
Essa sequência de eventos é mostrada na Figura B.7.
O Mach 3.0 oferece uma alternativa ao NetMsgServer
como parte de seu suporte aperfeiçoado a multiprocessadores
3 8   Apêndice B
sistema A sistema B
processo processo
de de
usuário usuário
NetMsg- NetMsg-
Server Server
emissor receptor
Figura B.7 Encaminhamento de IPC de rede pelo
NetMsgServer.
NORMA. O subsistema de IPC NORMA do Mach 3.0 imple-
menta funcionalidade semelhante a do NetMsgServer, dire-
tamente no kernel, fornecendo uma IPC entre os nós muito
mais eficiente para multicomputadores com hardware de inter-
conexão rápido. Por exemplo, a demorada cópia de mensa-
gens entre o NetMsgServer e o kernel é eliminada. O uso da
IPC NORMA não exclui o uso do NetMsgServer; ele ainda
pode ser usado para fornecer o serviço de IPC do Mach por
B.6 Gerenciamento de Memória
Dada a natureza orientada a objetos do Mach, não é surpresa
que uma abstração fundamental seja o objeto memória. Obje-
tos memória são usados para gerenciar memória secundária
e, geralmente, representam arquivos, pipes ou outros dados
que sejam mapeados na memória virtual, para leitura e gra-
vação (Figura B.8). Objetos memória podem ser apoiados por
gerenciadores de memória de nível de usuário que tomam o
lugar do paginador de memória virtual incorporado ao ker-
nel, mais tradicional, encontrado em outros sistemas ope-
racionais. Ao contrário da abordagem tradicional em que o
kernel gerencia a memória secundária, o Mach trata objetos
memória secundária (geralmente arquivos) como todos os
outros objetos do sistema. Cada objeto tem uma porta asso-
ciada a ele e pode ser manipulado por mensagens enviadas
a essa porta. Os objetos memória – diferente das rotinas de
gerenciamento de memória em kernels tradicionais monolí-
ticos – permitem a fácil experimentação de novos algoritmos
de manipulação da memória.
B.6.1 Estrutura Básica
O espaço de endereçamento virtual de uma tarefa é, em geral,
esparso e composto por muitas brechas de espaço não alo-
cado. Por exemplo, um arquivo mapeado para a memória é
colocado em algum conjunto de endereços. Mensagens gran-
meio de redes que conectem um multiprocessador NORMA a
outros computadores. Além da IPC NORMA, o Mach 3.0 tam-
bém dá suporte ao gerenciamento de memória em um sistema
NORMA e o recurso pelo qual uma tarefa desse sistema pode
criar tarefas filhas em nós que não sejam os seus. Esses recur-
sos dão suporte à implementação de um sistema operacional de
imagem única em um multiprocessador NORMA; o multipro-
cessador se comporta como um sistema grande e não como um
agrupamento de sistemas menores (tanto para usuários quanto
para aplicações).
B.5.4 Sincronização Através da IPC
O mecanismo de IPC é extremamente flexível e é usado em
todo o Mach. Por exemplo, ele pode ser usado na sincroniza-
ção de threads. Uma porta pode ser usada como variável de
sincronização e ter n mensagens enviadas para ela por n recur-
sos. Qualquer thread que queira usar um recurso executa uma
chamada de recebimento nessa porta. O thread receberá uma
mensagem se o recurso estiver disponível; caso contrário, ele
esperará na porta até que uma mensagem esteja disponível
nesse local. Para devolver um recurso após utilizá-lo, o thread
pode enviar uma mensagem à porta. Neste aspecto, o recebi-
mento é equivalente à operação de semáforo wait e o envio
é equivalente a signal. Esse método pode ser usado na sin-
cronização de operações de semáforo entre threads da mesma
tarefa, mas não pode ser usado na sincronização entre tarefas
porque apenas uma tarefa pode ter direitos de recebimento em
uma porta. Para obter mais semáforos de uso geral, podemos
criar um daemon simples que implemente o mesmo método.
des também são transferidas como segmentos de memória
compartilhada. Para cada um desses segmentos, uma seção
de endereço de memória virtual é usada para conceder aos
threads acesso à mensagem. À medida que novos itens são
mapeados para o espaço de endereçamento ou dele removi-
dos, brechas de memória não alocada aparecem no espaço de
endereçamento.
O Mach não tenta comprimir o espaço de endereça-
mento, embora uma tarefa possa falhar (ou cair) se não hou-
ver lugar, em seu espaço de endereçamento, para uma região
requerida. Considerando que os espaços de endereçamento
têm 4 GB ou mais, essa limitação não é, atualmente, um pro-
blema. No entanto, a manutenção de uma tabela de pági-
nas regular num espaço de endereçamento de 4 GB para
cada tarefa, especialmente um que contenha brechas, usaria
montantes excessivos de memória (1 MB ou mais). A chave
para espaços de endereçamento esparsos é que o espaço da
tabela de páginas seja usado apenas para regiões corrente-
mente alocadas. Quando ocorre um erro de página, o ker-
nel deve verificar se a página está em uma região válida, em
vez de simplesmente indexar a tabela de páginas e verificar
a entrada. Embora a busca resultante seja mais complexa, os
benefícios da redução dos requisitos de armazenamento na
memória e da manutenção de um espaço de endereçamento
mais simples tornam a abordagem válida.
 O Sistema Mach  3 9

espaço de
endereçamento
do usuário
entrada
anterior

próxima
cabeça cauda entrada

início/fim do
espaço de
endereçamento

dados dados não

texto pilha herança
inicializados inicializados

proteção
corrente/máxima

objeto
páginas
armazenadas
em cache deslocamento
nesse local
porta para
memória
entrada do mapa
secundária
objeto memória
virtual

Figura B.8 Mapas de endereços de tarefas na memória virtual do Mach.

O Mach também tem chamadas de sistema para dar suporte
à funcionalidade de memória virtual-padrão, incluindo alo-
cação, desalocação e cópia de memória virtual. Ao alocar um
novo objeto memória virtual, o thread pode fornecer um ende-
reço para o objeto ou deixar que o kernel escolha o endereço.
A memória física não é alocada até que as páginas desse objeto
sejam acessadas. A memória de retaguarda do objeto é geren-
ciada pelo paginador default (Seção B.6.2). Objetos memória
virtual também são alocados automaticamente quando uma
tarefa recebe uma mensagem contendo dados out-of-line.
Chamadas de sistema associadas retornam informações
sobre um objeto memória no espaço de endereçamento de uma
tarefa, alteram a proteção de acesso do objeto e especificam
como um objeto deve ser passado a tarefas filhas na hora de
sua criação (compartilhado, cópia após gravação ou ausente).
B.6.2 Gerenciadores de Memória de Nível
de Usuário
Um objeto de armazenamento secundário é mapeado para o
espaço de endereçamento virtual de uma tarefa. O Mach man-
tém um cache de páginas de todos os objetos mapeados residen-
tes na memória, como em outras implementações de memória
virtual. No entanto, um erro de página que ocorra quando um
thread acessa uma página não residente, é executado como
uma mensagem para a porta do objeto. O conceito de que um
objeto memória pode ser criado e servido por tarefas não tra-
tadas pelo kernel (diferente dos threads, por exemplo, que são
criados e mantidos somente pelo kernel) é importante. O resul-
tado final é que, no sentido tradicional, a memória pode ser
paginada por gerenciadores de memória escritos pelo usuário.
Quando o objeto é destruído, cabe ao gerenciador de memó-
ria gravar de volta, na memória secundária, quaisquer páginas
alteradas. Nenhuma suposição é feita pelo Mach sobre o con-
teúdo ou a importância dos objetos memória e, portanto, os
objetos memória são independentes do kernel.
Em várias circunstâncias, os gerenciadores de memória de
nível de usuário são insuficientes. Por exemplo, uma tarefa, ao
alocar uma nova região de memória virtual, pode não ter um
gerenciador de memória atribuído a essa região, já que ela não
representa um objeto de armazenamento secundário (mas deve
ser paginada), ou um gerenciador de memória pode deixar de
executar remoção de páginas da memória. O próprio Mach
também precisa de um gerenciador de memória para cuidar
de suas necessidades de memória. Para esses casos, o Mach for-
nece um gerenciador de memória default. O gerenciador de
memória default do Mach 2.5 usa o sistema de arquivos-padrão
para armazenar dados que devem ser gravados em disco, em
vez de requerer um espaço de permuta separado, como no 4.3
BSD. No Mach 3.0 (e no OSF/1), o gerenciador de memória
default pode usar tanto arquivos de um sistema de arquivos-
padrão como partições de disco dedicadas. O gerenciador de
memória default tem uma interface semelhante à dos geren-
ciadores de nível de usuário, com algumas extensões, para dar
suporte ao seu papel como o gerenciador de memória ao qual
4 0   Apêndice B
podemos confiar a execução da remoção de páginas quando
gerenciadores de nível de usuário deixam de fazê-la.
A política de remoção de páginas é implementada por um
thread interno do kernel, o daemon de pageout. Um algoritmo
de paginação baseado em FIFO com segunda chance (Seção
9.4.5) é usado para selecionar páginas a serem substituídas. As
páginas selecionadas são enviadas ao gerenciador apropriado
(de nível de usuário ou default) para a remoção real de páginas.
Um gerenciador de nível de usuário pode ser mais inteligente
do que o gerenciador default e pode implementar um algo-
ritmo de paginação diferente, adequado ao objeto ao qual ele
está dando suporte (isto é, selecionando alguma outra página
e removendo-a à força). Se um gerenciador de nível de usuário
não conseguir reduzir o conjunto de páginas residentes quando
solicitado a fazer isso pelo kernel, o gerenciador de memória
default é invocado e ele remove da memória o gerenciador
de nível de usuário para reduzir o tamanho do conjunto resi-
dente desse gerenciador. Se o gerenciador de nível de usuário
se recuperar do problema que o impediu de executar suas pró-
prias remoções de páginas, ele acessará essas páginas (fazendo
o kernel trazê-las para a memória novamente) e poderá então
removê-las como achar melhor.
Se um thread precisa acessar dados em um objeto memó-
ria (por exemplo, um arquivo), ele invoca a chamada de sis-
tema vm_map. Essa chamada de sistema inclui uma porta
que identifica o objeto e o gerenciador de memória que é res-
ponsável pela região. O kernel executa chamadas nessa porta
quando dados estão para ser lidos dessa região ou nela grava-
dos. Uma complexidade adicional é que o kernel faz essas cha-
madas assincronamente, já que não seria razoável que o kernel
servisse um thread de nível de usuário. Diferente da situação da
remoção de páginas, o kernel não tem o que fazer se sua solici-
tação não for atendida pelo gerenciador de memória externo.
Ele não tem conhecimento do conteúdo de um objeto ou de
como esse objeto deve ser manipulado.
Os gerenciadores de memória são responsáveis pela consis-
tência do conteúdo de um objeto memória, mapeado por tare-
fas em diferentes máquinas. (Tarefas em uma única máquina
compartilham uma única cópia de um objeto memória mapeado.)
Considere uma situação em que tarefas em duas máquinas dife-
rentes tentem modificar, concorrentemente, a mesma página
de um objeto. Cabe ao gerenciador decidir se essas modifica-
ções devem ser serializadas. Um gerenciador conservador, ao
implementar uma consistência rigorosa de memória, obriga-
ria as modificações a serem serializadas, concedendo acesso de
gravação a apenas um kernel de cada vez. Um gerenciador mais
sofisticado poderia permitir que os dois acessos ocorressem
concorrentemente (por exemplo, se o gerenciador soubesse
que as duas tarefas estavam modificando áreas distintas den-
tro da página e que ele poderia mesclar as modificações, com
sucesso, em algum momento futuro). A maioria dos gerencia-
dores de memória externos escritos para o Mach (por exemplo,
os que implementam arquivos mapeados) não implementam
lógica para lidar com kernels múltiplos, devido à complexidade
dessa lógica.
Quando a primeira chamada vm_map é feita em um objeto
memória, o kernel envia uma mensagem à porta do geren-
ciador de memória, incluída na chamada, invocando a rotina
memory_manager_init que o gerenciador de memória
deve fornecer, como parte de seu suporte a um objeto memó-
ria. As duas portas passadas para o gerenciador de memória
são a porta de controle e a porta de nome. A porta de con-
trole é usada pelo gerenciador de memória para fornecer dados
ao kernel – por exemplo, páginas a se tornarem residentes. As
portas de nome são usadas em todo o Mach. Elas não rece-
bem mensagens, mas são usadas simplesmente como um ponto
de referência e comparação. Para concluir, o objeto memória
deve responder a uma chamada memory_manager_init
com uma chamada memory_object_set_attributes
para indicar que está pronto para aceitar solicitações. Quando
todas as tarefas com direitos de envio para um objeto memó-
ria, abandonam esses direitos, o kernel desaloca as portas do
objeto, liberando assim o gerenciador de memória e o objeto
memória para destruição.
Várias chamadas do kernel são necessárias para dar suporte
a gerenciadores de memória externos. A chamada vm_map já
foi discutida no parágrafo acima. Além dela, alguns comandos
obtêm e configuram atributos e fornecem trancamento no nível
de página quando ele é necessário (por exemplo, depois que um
erro de página ocorreu, mas antes que o gerenciador de memó-
ria tenha retornado os dados apropriados). Outra chamada é
usada pelo gerenciador de memória para passar uma página
(ou várias páginas, se estiver sendo usada leitura antecipada)
para o kernel em resposta a um erro de página. Essa chamada
é necessária já que o kernel invoca o gerenciador de memó-
ria assincronamente. Para concluir, várias chamadas permitem
que o gerenciador de memória reporte erros ao kernel.
O próprio gerenciador de memória deve dar suporte a
várias chamadas para poder suportar um objeto. Já discuti-
mos memory_object_init e outras. Quando um thread
causa um erro de página em uma página do objeto memória,
o kernel envia uma memory_object_data_request à
porta do objeto memória em nome do thread que causou o
erro. O thread é colocado em estado de espera até o gerencia-
dor de memória retornar a página em uma chamada memory_
object_data_provided ou retornar um erro apropriado
ao kernel. Qualquer página que tenha sido modificada ou qual-
quer página preciosa que o kernel precise remover da memória
residente (devido ao envelhecimento da página, por exemplo),
é enviada ao objeto memória por intermédio de memory_
object_data_write. Páginas preciosas são páginas que
podem não ter sido modificadas, mas que não podem ser des-
cartadas, como de outro modo seriam, porque o gerencia-
dor de memória não retém mais uma cópia. O gerenciador de
memória declara essas páginas como preciosas e espera que o
kernel as retorne quando elas são removidas da memória. As
páginas preciosas evitam a duplicação e a cópia desnecessárias
da memória.
Ainda há varias outras chamadas para trancamento, infor-
mações de proteção e modificação e os outros detalhes com os
quais todos os sistemas de memória virtual devem lidar.
Na versão atual, o Mach não permite que gerenciadores de
memória externos afetem diretamente o algoritmo de substitui-
ção de páginas. O Mach não exporta as informações de acesso

à memória que seriam necessárias para que uma tarefa externa
selecione a página menos recentemente usada, por exemplo.
Métodos para fornecer essas informações estão sendo investi-
gados atualmente. Um gerenciador de memória externo conti-
nua sendo útil por várias razões, no entanto:
• Ele pode rejeitar o alvo que o kernel deseja substituir se sou-
ber de uma candidata melhor (por exemplo, a substituição de
páginas MRU).
• Ele pode monitorar o objeto memória ao qual estiver dando
suporte e solicitar que páginas sejam removidas antes que a
memória invoque, como de costume, o daemon de pageout
do Mach.
• Ele é particularmente importante para manter a consistência
da memória secundária no caso de threads de processadores
múltiplos, como mostramos na Seção B.6.3.
• Ele pode controlar a ordem de operações na memória secun-
dária para impor restrições de consistência demandadas por
sistemas de gerenciamento de bancos de dados. Por exemplo,
para registrar o histórico de transações, estas devem ser gra-
vadas em um arquivo de log em disco antes de modificarem
os dados do banco de dados.
• Ele pode controlar o acesso a arquivos mapeados.
B.6.3 Memória Compartilhada
O Mach usa memória compartilhada para reduzir a complexi-
dade de vários recursos do sistema, assim como para fornecer
esses recursos de maneira eficiente. A memória comparti-
lhada, em geral, permite comunicação extremamente rápida
entre processos, reduz o overhead no gerenciamento de arqui-
vos e ajuda a suportar multiprocessamento e gerenciamento de
bancos de dados. No entanto, o Mach não usa memória com-
partilhada para todos esses papéis tradicionais da memória
compartilhada. Por exemplo, todos os threads de uma tarefa
compartilham a memória dessa tarefa e, portanto, nenhum
recurso formal de memória compartilhada é necessário den-
tro de uma tarefa. Porém, o Mach ainda deve fornecer memória
compartilhada tradicional para dar suporte a outros construto-
res do sistema operacional, como a chamada de sistema fork
do UNIX.
É obviamente difícil que tarefas de várias máquinas com-
partilhem memória e mantenham a consistência dos dados.
O Mach não tenta resolver esse problema diretamente; em
vez disso, ele fornece recursos para permitir que o problema
seja resolvido. O Mach suporta memória compartilhada con-
B.7 Interface do Programador
Um programador pode trabalhar em vários níveis dentro do Mach.
É claro que há o nível de chamadas de sistema que, no Mach 2.5, é
equivalente à interface de chamadas de sistema do 4.3 BSD. A ver-
são 2.5 inclui grande parte do 4.3 BSD como um thread no kernel.
Uma chamada de sistema BSD faz a interceptação para o kernel
e é atendida por esse thread em nome do chamador, de maneira
semelhante a como o BSD-padrão a manipularia. A emulação não
é multithreads e, portanto, tem eficiência limitada.
O Sistema Mach  4 1
sistente apenas quando esta é utilizada por tarefas executadas
em processadores que compartilhem memória. Uma tarefa pai
pode declarar as regiões de memória que devem ser herdadas
por seus filhos e quais regiões devem ser de leitura-gravação.
Esse esquema é diferente da herança com cópia após grava-
ção em que cada tarefa mantém sua própria cópia de quaisquer
páginas alteradas. Um objeto gravável é endereçado a partir
do mapa de endereços de cada tarefa e todas as alterações são
feitas na mesma cópia. Os threads das tarefas são responsáveis
por coordenar as alterações na memória para que elas não
afetem uns aos outros (gravando na mesma locação concor-
rentemente). Essa coordenação pode ser feita por meio dos
métodos normais de sincronização: seções críticas ou locks
de exclusão mútua.
Para o caso de memória compartilhada entre máqui-
nas separadas, o Mach permite o uso de gerenciadores de
memória externos. Se um conjunto de tarefas não relacio-
nadas quer compartilhar uma seção de memória, as tare-
fas podem usar o mesmo gerenciador de memória externo
e acessar as mesmas áreas de memória secundária por seu
intermédio. O implementador desse sistema teria que escre-
ver as tarefas e o paginador externo. Esse paginador poderia
ser muito simples ou muito complicado, conforme neces-
sário. Uma implementação simples não permitiria leituras
enquanto uma página estivesse sendo gravada. Qualquer
tentativa de gravação faria o paginador invalidar a página
em todas as tarefas que a estivessem acessando no momento.
O paginador permitiria, então, a gravação e revalidaria as
leituras com a nova versão da página. Os leitores simples-
mente acompanhariam a manipulação de um erro de página
até a página se tornar novamente disponível. O Mach for-
nece um gerenciador de memória como esse: o Network
Memory Server (NetMemServer). Para multicomputadores,
a configuração NORMA do Mach 3.0 fornece suporte seme-
lhante como parte-padrão do kernel. Esse subsistema XMM
permite que sistemas multicomputadores usem gerenciado-
res de memória externos que não incorporem lógica para
manipulação de kernels múltiplos; o subsistema XMM é res-
ponsável por manter a consistência dos dados entre ker-
nels múltiplos que compartilhem memória e por fazer com
que esses kernels pareçam um único kernel para o gerencia-
dor de memória. O subsistema XMM também implementa
lógica de cópia virtual para os objetos mapeados que ele
gerencia. Essa lógica de cópia virtual inclui tanto cópia após
referência entre kernels multicomputadores quanto otimi-
zações sofisticadas de cópia após gravação.
O Mach 3.0 abandonou o modelo de servidor único para
dar suporte a servidores múltiplos. Portanto, ele se tornou
um verdadeiro microkernel, sem todos os recursos normal-
mente encontrados em um kernel. Em vez disso, toda a fun-
cionalidade pode ser fornecida por intermédio de bibliotecas
de emulação, de servidores ou de uma combinação dos dois.
Para manter a definição de microkernel, as bibliotecas de emu-
lação e servidores executam fora do kernel em nível de usuário.
4 2   Apêndice B
Dessa forma, vários sistemas operacionais podem ser executa-
dos concorrentemente em um kernel do Mach 3.0.
Uma biblioteca de emulação é um conjunto de rotinas que
reside em uma parte somente de leitura do espaço de endereça-
mento de um programa. Quaisquer chamadas do sistema ope-
racional que o programa faça, são convertidas em chamadas
de sub-rotinas para a biblioteca. Sistemas operacionais monou-
suários, como o MS-DOS e o sistema operacional Macintosh,
têm sido implementados exclusivamente como bibliotecas
de emulação. Por razões de eficiência, a biblioteca de emula-
ção reside no espaço de endereçamento do programa que pre-
cisa de sua funcionalidade; mas, em teoria, ela poderia ser uma
tarefa separada.
Sistemas operacionais mais complexos são emulados por
meio do uso de bibliotecas e de um ou mais servidores. Chama-
das de sistema que não possam ser implementadas na biblio-
teca, são redirecionadas ao servidor apropriado. Os servidores
podem ser multithreads para aumentar a eficiência; o BSD e o
OSF/1 são implementados como servidores multithreads indi-
viduais. Os sistemas podem ser decompostos em vários servi-
dores, para maior modularidade.
Funcionalmente, uma chamada de sistema começa em uma
tarefa e passa pelo kernel antes de ser redirecionada, se apro-
priado, à biblioteca do espaço de endereçamento da tarefa ou
a um servidor. Embora essa transferência de controle adicio-
nal diminua a eficiência do Mach, essa diminuição é um pouco
amenizada pela capacidade de threads múltiplos executarem,
concorrentemente, códigos semelhantes aos do BSD.
B.8
O sistema operacional Mach é projetado para incorporar as
várias inovações recentes da pesquisa em sistemas operacio-
nais e produzir um sistema operacional totalmente funcional e
tecnicamente avançado.
O Mach foi projetado visando três objetivos críticos:
• Emular o UNIX 4.3 BSD de modo que os arquivos execu-
táveis de um sistema UNIX possam ser executados correta-
mente sob o Mach.
• Ser um sistema operacional moderno que suporte muitos
modelos de memória, bem como computação paralela e dis-
tribuída.
• Obter um kernel mais simples e fácil de modificar do que o
4.3 BSD.
Como mostramos, o Mach está a caminho de alcançar esses
objetivos.
O Mach 2.5 inclui o 4.3 BSD em seu kernel, o que fornece a
emulação necessária, mas aumenta o kernel. Esse código do 4.3
BSD foi reescrito para fornecer a mesma funcionalidade do 4.3,
mas utilizando as primitivas do Mach. Tal alteração permite
Exercícios
B.1 Quais são os três recursos do Mach que o tornam apropriado
ao processamento distribuído?
No próximo nível mais alto de programação está o pacote
de threads C. Esse pacote é uma biblioteca de tempo de exe-
cução que fornece uma interface da linguagem C para as
primitivas de threads básicas do Mach. Ele fornece acesso
conveniente a essas primitivas, incluindo rotinas para cria-
ção e junção de threads, exclusão mútua por meio de variá-
veis mutex (Seção B.4.2) e sincronização por meio do uso de
variáveis de condição. Infelizmente, não é apropriado que o
pacote de threads C seja usado entre sistemas que não com-
partilhem memória (sistemas NORMA) porque ele depende
de memória compartilhada para implementar seus constru-
tores. Atualmente, não há algo equivalente aos threads C para
sistemas NORMA. Outras bibliotecas de tempo de execução
têm sido escritas para o Mach, inclusive o suporte de threads
a outras linguagens.
Embora o uso de primitivas torne o Mach flexível, tam-
bém torna muitas tarefas de programação repetitivas. Por
exemplo, quantidades significativas de código são associadas
ao envio e recebimento de mensagens por tarefas que usem
mensagens (que, no Mach, são quase todas). Portanto, os
projetistas do Mach fornecem um gerador de interfaces (ou
gerador de stubs) chamado MIG. O MIG é, essencialmente,
um compilador que recebe, como entrada, uma definição da
interface a ser usada (declarações de variáveis, tipos e proce-
dimentos) e gera o código de interface RPC necessário para
enviar e receber as mensagens que estejam de acordo com
essa definição e para conectar as mensagens aos threads emis-
sores e receptores.
Resumo
que o código de suporte do 4.3 BSD seja executado no espaço
do usuário, em um sistema Mach 3.0.
O Mach usa processos peso-leves, na forma de threads de
execução múltiplos dentro de uma tarefa (ou espaço de ende-
reçamento), para suportar multiprocessamento e computação
paralela. Seu uso extensivo de mensagens, como único método
de comunicação, assegura que os mecanismos de proteção
sejam completos e eficientes. Ao integrar as mensagens ao sis-
tema de memória virtual, o Mach também assegura a sua mani-
pulação eficiente. Para concluir, ao fazer o sistema de memória
virtual usar mensagens para se comunicar com os daemons que
gerenciam a memória de retaguarda, o Mach fornece grande
flexibilidade ao projeto e à implementação dessas tarefas de
gerenciamento do objeto memória.
Ao fornecer chamadas de sistema de baixo nível, ou pri-
mitivas, a partir das quais funções mais complexas possam ser
construídas, o Mach reduz o tamanho do kernel ao mesmo
tempo em que permite a emulação do sistema operacional no
nível do usuário, de forma muito semelhante aos sistemas de
máquina virtual da IBM.
B.2 Cite duas maneiras pelas quais os conjuntos de portas sejam
úteis na implementação de programas paralelos.

B.3 Considere uma aplicação que mantenha um banco de dados
e forneça recursos para que outras tarefas incluam e excluam
informações ou consultem o banco de dados. Forneça três
configurações de portas, threads e tipos de mensagens que
poderiam ser usadas para implementar esse sistema. Qual é
a melhor? Explique sua resposta.
B.4 Descreva uma tarefa que promova a migração de subtarefas
(tarefas criadas por ela) para outros sistemas. Inclua
informações sobre como ela decidiria quando migrar as
tarefas, que tarefas seriam migradas e como a migração
ocorreria.
B.5 Cite dois tipos de aplicações para as quais você usaria o pacote
MIG.
B.6 Por que alguém usaria chamadas de sistema de baixo nível
em lugar do pacote de threads C?
Notas Bibliográficas
O sistema operacional Accent foi descrito por Rashid e Robert-
son [1981]. Uma visão geral histórica da evolução desde um
sistema ainda mais antigo, o RIG, passando pelo Accent até o
Mach foi fornecida por Rashid [1986]. Discussões gerais rela-
cionadas ao modelo do Mach foram oferecidas por Tevanian e
Smith [1989].
Accetta et al. [1986] apresentaram uma visão geral do pro-
jeto original do Mach. O scheduler do Mach foi descrito em
detalhes por Tevanian et al. [1987a] e Black [1990]. Uma ver-
são mais antiga do sistema de mapeamento de memória e de
memória compartilhada do Mach foi apresentada por Teva-
nian et al. [1987b].
A descrição mais atual do pacote de threads C apareceu
em Cooper e Draves [1987]; o MIG foi descrito por Draves et
al. [1989]. Uma visão geral da funcionalidade desses pacotes e
uma introdução geral à programação no Mach foram apresen-
tadas por Walmer e Thompson [1989] e Boykin et al. [1993].
Black et al. [1988] discutiram o recurso de manipulação
de exceções do Mach. Um depurador multithreads, com base
nesse mecanismo, foi descrito em Caswell e Black [1989].
Uma série de palestras sobre o Mach, patrocinadas pelo
consórcio UNIX da OSF, está disponível em videotape da OSF.
Créditos
As Figuras B.1, B.6 e B.8 foram reproduzidas com permissão
da Open Software Foundation, Inc. Extraídas da Mach Lecture
Series, OSF, outubro de 1989, Cambridge, Massachusetts.
As Figuras B.1 e B.8 foram apresentadas por R. Rashid da
Carnegie Mellon University e a Figura B.7 foi apresentada por
D. Julin também da Carnegie Mellon University.
O Sistema Mach  4 3
B.7 Por que os gerenciadores de memória externos não conseguem
substituir os algoritmos internos de substituição de páginas?
De que informações os gerenciadores externos precisariam
para tomar decisões de substituição de páginas? Por que o
fornecimento dessas informações violaria o princípio que
embasa os gerenciadores externos?
B.8 Por que é difícil implementar exclusão mútua e variáveis
de condição em um ambiente no qual CPUs semelhantes
não compartilham qualquer memória? Que abordagem e
mecanismo poderiam ser usados para tornar esses recursos
disponíveis em um sistema NORMA?
B.9 Quais são as vantagens de reescrever o código do 4.3 BSD
como uma biblioteca de nível de usuário externa, em vez de
deixá-lo como parte do kernel do Mach? Há desvantagens?
Explique sua resposta.
Os tópicos incluem uma visão geral, threads, conexão de rede,
gerenciamento de memória, muitos detalhes internos e alguns
exemplos de implementações do Mach. Os slides dessas pales-
tras foram fornecidos pela OSF [1989].
O grupo de notícias comp.os.mach, acessível em sistemas
em que o USENET News está disponível (a maioria das insti-
tuições educacionais dos Estados Unidos e algumas em outros
países), é usado na troca de informações sobre o projeto do
Mach e seus componentes.
Uma visão geral da estrutura do microkernel do Mach 3.0,
complementada com análises de desempenho do Mach 2.5 e
3.0 comparadas com outros sistemas, foi fornecida em Black et
al. [1992]. Detalhes dos mecanismos internos do kernel e das
interfaces do Mach 3.0 foram fornecidos em Loepere [1992].
Tanenbaum [1992] apresentou uma comparação entre o Mach
e o Amoeba. Discussões relacionadas ao paralelismo no Mach
e no 4.3 BSD foram oferecidas por Boykin e Langerman [1990].
Pesquisas em andamento foram apresentadas em USENIX
Mach and Microkernel Symposia [USENIX 1990, USENIX 1991
e USENIX 1992b]. Áreas ativas de pesquisa incluem memó-
ria virtual, tempo real e segurança (McNamee e Armstrong
[1990]).
A Figura B.6 foi reproduzida de Accetta, Baron, Bolosky,
Golub, Rashid, Tevanian e Young, “Mach: A New Kernel Foun-
dation for UNIX Development”, Proceedings of Summer
USENIX, junho de 1986, Atlanta, Georgia. Reimpressa com
permissão dos autores.