Você está na página 1de 10

Mac os X – Um sistema operacional revolucionário

Nomes: Júlio César, Kaliany e Thaina Marini

Resumo:
Neste artigo, discutiremos vários aspectos técnicos do Mac OS X, incluindo
estruturas e abstrações de dados, gerenciamento de threads, comunicação entre
objetos, exclusão e sincronização mútuas, gerenciamento de memória e sistema de
arquivos. Limitamos nossa discussão aos elementos encontrados no ambiente do
kernel do Mac OS X.

Palavras-chave: Aspectos técnicos, sistema operacional, Darwin Kernel.

Introdução:

No início da década de 1990, a Apple Computer, Inc. começou a planejar a criação


de um sistema operacional (SO) de próxima geração; A Apple esperava criar um
sistema operacional que fosse estável, portátil, fácil de usar e oferecesse melhorias
de desempenho em relação ao atual Mac OS (Glaser, 2001). Em fevereiro de 1994,
a Apple anunciou o início do Copland, o primeiro empreendimento da Apple para
criar um sistema operacional moderno. Em agosto de 1996, a Apple acabou com o
projeto Copland porque “Copland sugou muito dinheiro, recursos e tempo da Apple e
acabou entregando... nada. Depois de anos de promessas e incontáveis milhões
(bilhões?) gastos no projeto, a Apple engavetou suas tentativas de construir seu
próprio sistema operacional de próxima geração e começou a olhar para fora da
empresa” (Garfinkel & Mahoney, 2002). Eventualmente, a Apple decidiu comprar a
NeXT, Inc., fundada pelo cofundador da Apple, Steve Jobs, por US$ 430 milhões
(Mesa, 1998). A aquisição da NeXT permitiu que a Apple usasse o sistema
operacional da NeXT, chamado NeXTSTEP, como base para seu novo sistema
operacional. Este novo projeto recebeu o codinome Rhapsody e, após incontáveis
horas de trabalho de integração, foi lançado ao público como Mac OS X em março
de 2001., e desempenho." (Apple, 2003) O novo sistema operacional introduziu uma
série de novos recursos, incluindo multitarefa preemptiva, memória protegida,
gerenciamento avançado de memória, multiprocessamento simétrico e muito mais
(Glaser & Reynolds, 2003).
O Mac OS X é construído usando o Darwin Kernel, um núcleo baseado em UNIX de
código aberto construído em cima de um microkernel Mach 3.0 junto com serviços
principais 4.4BSD. No topo do Darwin está o sistema gráfico Quartz, OpenGL e
Quicktime. O Quartz fornece um servidor de janela, bem como uma biblioteca de
renderização de gráficos que usa PDF (Portable Document Format) como modelo de
imagem. OpenGL é o padrão da indústria para gráficos 2D e 3D de ponta. Quicktime
é uma tecnologia projetada pela Apple para armazenamento, manipulação,
aprimoramento e streaming de multimídia, como vídeos ou animações. Além desses
mecanismos gráficos, há várias APIs de programação diferentes, como Cocoa,
Carbon, Classic e Java; todas essas APIs fornecem uma maneira de o mecanismo
gráfico interagir com o Aqua, a interface do usuário desenvolvida especificamente
para Mac OS X (Maçã 3, 2003).

Desde então, a Apple lançou três versões do Mac OS X desde seu lançamento
inicial em março de 2001: 10.1 em setembro de 2001, 10.2 (codinome Jaguar) em
agosto de 2002 e, mais recentemente, 10.3 (codinome Panther) em outubro de
2003. sistema introduziu melhorias de desempenho, maior estabilidade e novos
recursos para computadores Apple; essas inovações, bem como a facilidade com
que os aplicativos podem ser criados para o Mac OS X, estimularam mais de cinco
milhões de usuários a adotar o Mac OS X em janeiro de 2003 (Apple 2, 2003). Os
avanços feitos no sistema operacional, aliados com novos lançamentos de
hardware, como o iPod, Power Macintosh G5 e iMac, combinaram-se para tirar a
Apple dos problemas financeiros encontrados no início dos anos 1990. O Mac OS X
foi projetado para ser executado exclusivamente no hardware da Apple. Há uma boa
razão para isso; A Apple é principalmente uma empresa de hardware. Suas receitas
de hardware excedem em muito as receitas de software. O Mac OS X e muitos
outros aplicativos de software projetados pela Apple destinam-se a aumentar a
comercialização do hardware da Apple (e é por isso que muitos programas de
aplicativos de qualidade da Apple são fornecidos gratuitamente). O hardware de
computador da Apple inclui servidores, sistemas de desktop de nível profissional e
de consumo e sistemas de laptop de nível profissional e de consumo. Os sistemas
de computador da Apple incluem arquiteturas de 32 bits e 64 bits. Esses são os
únicos ambientes de hardware nos quais o Mac OS X foi projetado para ser
executado, permitindo à Apple um grande controle sobre a integração do hardware e
do sistema operacional. Por exemplo, devido ao suporte a multiprocessamento
simples e poderoso do Mac OS X, a Apple quase sempre inclui configurações de
processador duplo em sua linha. O Mac OS X foi projetado como um sistema
multiusuário. Ele pode ser facilmente implementado em uma rede. No Mac OS X, a
Apple tentou preservar a facilidade de uso encontrada nas versões anteriores do
Mac OS, manter sua base de mercado com profissionais criativos e expandir para
novos mercados.
Características

1.1 Estruturas de dados e abstrações


Como o Mach possui um design fundamentalmente orientado a objetos, é importante
entender as abstrações e estruturas de dados definidas no Mach antes de
prosseguir com uma discussão sobre o sistema operacional Macintosh. Também
será útil explicar algumas das estruturas de dados específicas do Mac OS X. A
unidade fundamental de propriedade de recursos em Mach é a tarefa. Uma tarefa é
semelhante, mas não idêntica, a um processo. A distinção é mais aparente no
gerenciamento de threads. Embora um thread "pertença" a uma tarefa em particular,
e só possa ser acessada através das portas dessa tarefa, para fins de execução
Mach não se importa se duas threads vêm da mesma tarefa ou de tarefas distintas.
Na falta de um processo tradicional, em Mach, o thread é a unidade básica e única
de execução. O Mac OS X define um processo na parte BSD do kernel para
representar um programa em execução. Nesse sentido, um processo representa
uma tarefa Mach e um certo número de threads Mach. A noção de processo é
importante para fins de controle de execução de alto nível. Mais informações sobre
threads e threads de processamento são abordadas em uma seção posterior deste
documento. (Rashid et al. 1987, Apple KP 2003) Cada tarefa consiste em um espaço
de endereço virtual (4 GB no OS X), algum número de portas e algum número de
threads. Uma porta é o canal de comunicação para qualquer objeto. As portas são
protegidas pelo kernel para que qualquer objeto que envie uma mensagem para
uma porta tenha o direito de porta apropriado (permissão). Os direitos de porta são
passados por herança ou concedidos pelo kernel. Os direitos de porta também são
discutidos em mais detalhes em uma seção posterior. (Apple KP 2003, Silberschatz
et al. 2 2003) Uma abstração final de Mach é o objeto de memória. Embora vários
objetos de memória possam estar dentro do espaço de endereço de uma tarefa
específica, a tarefa não possui esses objetos de memória. Objetos de memória são
de propriedade de gerenciadores de memória, que podem ser em nível de usuário
ou em nível de kernel. Mais informações sobre objetos de memória e gerenciadores
de memória são abordadas na seção Gerenciamento de memória. (Apple KP 2003).

1.2 Gerenciamento de threads


Vale a pena notar mais uma vez que, embora uma tarefa seja de certa forma
comparável a um processo, existem diferenças suficientes para tornar a distinção
importante. Uma tarefa é uma coleção de recursos. Como tal, ele não tem um
"estado" como um processo. No Mac OS X, três estados são definidos para
encadeamentos: Pronto, Parado e Em execução. Eles correspondem aos estados
de processo tradicionais de Pronto, Aguardando e Em execução, respectivamente.
(Apple KP 2003) Uma semelhança entre tarefas e processos é que ambos são muito
caros para criar ou destruir. Os threads Mach são, como os threads em qualquer
outro sistema operacional, muito mais baratos para criar ou destruir. (Apple KP
2003) Embora o Mac OS X defina diferentes tipos de encadeamentos, no nível mais
baixo, cada encadeamento é um encadeamento Mach (um encadeamento no nível
do kernel). Essa estrutura permite grande flexibilidade no escalonamento de threads,
como veremos. No topo das threads Mach, o primeiro nível de definição de thread é
o pthread (thread POSIX). Todos os threads mach em execução no espaço do
usuário têm um pthread em camadas no topo de seu thread mach. Um pthread pode
suportar um thread NS (Cocoa), uma tarefa Carbon MP (multiprocessamento) (sem
relação com uma "tarefa" Mach) ou um thread cooperativo. (Maçã 2001) A vantagem
de ter todas as threads construídas em cima de threads Mach genéricos é que Mach
não vê diferença de tipo entre as várias threads do sistema. A tarefa que possui um
encadeamento é irrelevante para o agendador. São todos, simplesmente, fios Mach.
Como tal, Mach sempre segue suas políticas de agendamento para selecionar
threads para execução. Essa falta de controle do Mach possibilita o controle em um
nível superior, que é onde entram as várias definições de thread. entre os vários fios
cooperativos que lhe pertencem. Qualquer encadeamento sem o token será
bloqueado, então Mach selecionará o encadeamento com o token sobre todos
aqueles sem ele. Eventualmente, o encadeamento entregará o token ao Carbon
Thread Manager, que passará o token para o próximo encadeamento cooperativo.
Este é apenas um exemplo de muitos tipos de manipulações que podem afetar as
decisões de agendamento que Mach realmente toma. (Apple KP 2003, Apple 2001)
Mach disponibiliza várias políticas de agendamento. Três delas são recomendadas
no OS X: a Thread Standard Policy (uma política "justa" definida pelo sistema), a
Thread Time Constraint Policy (uma política de agendamento em tempo real flexível)
e a Thread Precedence Policy (uma política de prioridade). Todas essas políticas
usam preempção de acordo com os quanta de tempo. Os valores para os quanta de
tempo variam de acordo com a política de agendamento. Ao misturar diferentes
mensagens Mach com as várias políticas, obtém-se uma grande flexibilidade na
forma como o escalonamento de threads será tratado. No Mac OS X, o kernel não é
o único responsável pelo agendamento. (Apple KP 2003).
1.3 Exclusão mútua e sincronização
O Mac OS X usa um semáforo de contagem tradicional para obter a exclusão
mútua. O semáforo pertence a uma tarefa Mach em particular, e cada semáforo
deve ser atribuído a alguma tarefa quando é criado (isso é feito através de um
parâmetro na função semaphore_create. Esta tarefa também é responsável por
destruir o semáforo. O Mac OS X define três políticas para semáforos: FIFO (first-in
first-out), Fixed Priority e Prepost. A função da política FIFO deve ser óbvia. A
Prioridade Fixa reordena a fila de espera de acordo com as políticas de prioridade
de thread. Prepost proíbe a função semaphore_signal de incrementar o contador
quando não há threads na fila. Isso cria uma condição em que os encadeamentos
devem sempre esperar até que sejam sinalizados. (Apple KP 2003) O Mac OS X
também usa spinlocks, bloqueios de mutex e bloqueios de leitura e gravação. Como
a preempção no Mac OS X é baseada em quanta de tempo, um spinlock sempre
persistirá até que seu quantum de tempo expire. Por esse motivo, geralmente não
há vantagem de desempenho obtida com o uso de spinlocks para evitar trocas de
contexto. Como tal, os spinlocks são recomendados apenas onde os mutexes não
podem ser usados. Uma thread executa um sinal mutex quando está prestes a
entrar em sua seção crítica e, em seguida, bloqueia, produzindo o restante de seu
quantum de tempo. Em geral, isso é preferível a um spinlock, mas seu uso é limitado
a contextos onde o bloqueio é permitido. Em contextos onde o bloqueio não é
permitido (manipuladores de interrupção, por exemplo), os bloqueios mutex não
podem ser usados. Os bloqueios de leitura e gravação são os bloqueios que nem
sempre são exclusivos. Um bloqueio de leitura e gravação é implementado em uma
situação em que vários threads podem ler dados compartilhados, mas apenas um
pode gravar por vez sem causar problemas. Contanto que todos os threads que
mantêm o bloqueio estejam realizando leituras, qualquer número de threads pode
conter um bloqueio de leitura e gravação. No entanto, se algum thread pretender
escrever, ele deve bloquear até que todos os threads executando leituras liberem
seus bloqueios. (Apple KP 2003).

1.4 Comunicação Inter objeto


Como Mach não implementa processos, "comunicação entre processos" seria um
nome impróprio. Além disso, seria uma descrição inadequada, pois todos os objetos
Mach interagem da mesma maneira. Em Mach, cada objeto tem um certo número de
portas e certos direitos de porta. A comunicação de um objeto é passada em uma
mensagem para a porta de outro objeto. Um objeto só pode enviar uma mensagem
para uma porta para a qual possui o direito de porta apropriado. Cada porta permite
algum conjunto de possíveis operações ou comunicações possíveis, de modo que
um objeto só pode realizar aquelas operações que correspondem às portas que ele
pode acessar. Mach implementa um serviço de mensagens altamente simplificado.
Existem apenas três chamadas de sistema necessárias para a transmissão de
mensagens: msg_send (envia uma mensagem), msg_receive (recebe uma
mensagem) e msg_rpc (chamada de procedimento remoto, envia uma mensagem e
aguarda uma resposta). As mensagens de um único remetente são enfileiradas de
acordo com um esquema de primeiro a entrar, primeiro a sair. Tradicionalmente, as
implementações de esquemas de passagem de mensagens têm sofrido com o baixo
desempenho devido às frequentes operações de cópia necessárias (copiar a
mensagem do remetente para o destinatário, copiar a resposta desse objeto de volta
para o remetente original. Mach evita esse problema na maioria dos casos ao
mapear a memória que contém a mensagem no espaço de endereço do receptor
(nenhuma cópia é feita) (Silberschatz et al. 2 2003, Apple KP 2003, Silberschatz et
al. 2003)

1.5 Gerenciamento de memória


No Mac OS X, o Gerenciamento de Memória é tratado quase que exclusivamente
por ou através da parte Mach do kernel. Mach implementa um esquema de memória
virtual esparsa. Cada processo no Mac OS X recebe um espaço de endereço virtual
de quatro gigabytes, a maioria dos quais geralmente está vazia. Isso se destina a
minimizar os efeitos prejudiciais da fragmentação no espaço de memória disponível
de um processo. Se o espaço virtual de um aplicativo for suficientemente grande, é
improvável que qualquer página seja grande demais para caber em qualquer um dos
espaços disponíveis. (Apple KP 2003, Silberschatz et al. 2 2003) Manter um espaço
de endereço escasso é caro. O Mac OS X mantém uma tabela de páginas para cada
processo no sistema. Ter tabelas de páginas que fazem referência a quatro
gigabytes de espaço para cada processo no sistema usa muita memória (cerca de 1
megabyte por tabela de páginas, dependendo do tamanho da página). abordagem.
As tabelas de páginas são mantidas apenas para regiões válidas do espaço virtual
de um processo (essas páginas atribuídas). Isso resulta em maior sobrecarga no
acesso a um endereço: o kernel deve primeiro verificar se um endereço está em
uma região válida antes de ler o endereço especificado pela tabela de páginas. No
entanto, a sobrecarga compensa a economia de desempenho obtida por meio dessa
estrutura. (Silberschatz et al. 2 2003, Apple KP 2003) No Mac OS X (e no Mach) o
Virtual Memory System é implementado usando dois elementos primários: uma
abstração chamada Memory Object e Memory Managers. Em um nível baixo, a
memória é realmente gerenciada por meio de paginação de demanda usando um
FIFO (First In First Out) modificado com algoritmo de segunda chance implementado
pelo pager padrão. Esta é, no entanto, uma simplificação excessiva. Em um nível
superior, todas as páginas estão associadas a um objeto de memória específico.
Cada objeto de memória pertence a um gerenciador de memória. Os gerenciadores
de memória podem ser de nível de usuário ou de kernel. O pager padrão é um dos
três pagers no nível do kernel. Os outros pagers no nível do kernel incluem o pager
vnode (usado para arquivos mapeados na memória) e o pager de dispositivo (usado
para gerenciar a memória usada como cache ou buffer para dispositivos). (Rashid et
al. 1987, Apple KP 2003) Um objeto de memória é uma referência abstrata aos
dados (páginas) associados a ele e às proteções atribuídas a esses dados. Cada
objeto de memória tem portas e direitos de porta. Uma solicitação de uma página
associada a um objeto de memória específico envia uma mensagem para a porta
desse objeto. Se a entidade solicitante tiver os direitos de porta apropriados
(permissões), o objeto de memória tentará satisfazer a solicitação. Se a solicitação
produzir uma falha de página, a solicitação será feita ao gerenciador de memória
que possui o objeto para mapear a página apropriada para a memória física. O
conceito de fazer essa solicitação ao gerenciador de memória que possui o objeto
de memória é muito importante para entender o atual sistema de gerenciamento de
memória do Mach, bem como seu futuro. (Apple KP 2003)

1.6 Gerenciamento de memória externa


Cada objeto criado em Mach pode herdar permissões especificadas, ou direitos de
porta, de seu pai. Mach é o pai de todos os gerenciadores de memória de nível de
usuário, portanto, é capaz de passar a eles certos direitos de porta que governam a
substituição de página. Como tal, é possível para um gerenciador de memória
cuidadosamente escrito implementar um algoritmo de substituição de página que
seja superior (pelo menos para uma tarefa específica) do que o implementado pelo
kernel. Essa funcionalidade ainda não atingiu a maturidade total. Mach não tem
atualmente a capacidade de passar as informações necessárias para implementar,
por exemplo, um algoritmo de substituição de página usado menos recentemente
para gerenciadores de memória externos. Os métodos de implementação desta
capacidade estão sob investigação. No entanto, gerenciadores de memória externos
podem implementar algoritmos de substituição de página que não dependem de
informações que Mach não consegue passar (por exemplo, usadas mais
recentemente). Na realidade, os pagers não aplicam diretamente seu algoritmo de
substituição de página. Em vez disso, o pager padrão seleciona uma página de
vítima e passa uma mensagem para o gerenciador de memória que possui o objeto
apropriado para substituir essa página. O gerenciador de memória pode então
aceitar ou rejeitar a seleção do pager padrão. Além disso, gerenciadores de
memória externos podem solicitar pageouts e pageins independentemente de falhas
de página. Isso pode permitir que o gerenciador de memória "planeje com
antecedência" se puder paginar páginas que provavelmente não serão usadas
novamente em breve ou páginas em páginas que provavelmente serão usadas em
um futuro próximo e, assim, exercer algum controle sobre o mecanismo de
paginação. (Silberschatz et al. 2 2003, Apple KP 2003) Sistema de arquivos e
gerenciamento de arquivos O sistema de arquivos do Mac OS X segue convenções
Unix bastante padrão. Há um diretório raiz no topo da árvore, com acesso direto ou
indireto a todos os arquivos e outros diretórios do sistema. Imediatamente abaixo do
diretório raiz está um diretório de usuários que contém um diretório para cada
usuário com uma conta no sistema. Cada usuário tem uma home e seus próprios
diretórios, e nenhum usuário (exceto root) pode acessar os diretórios ou arquivos no
diretório pessoal de outro usuário. Um desvio incomum do sistema UNIX padrão é
que, quando o sistema é instalado pela primeira vez, a conta root não é configurada.
Isso é provavelmente para simplificar - muitos sistemas são de propriedade de
usuários que nunca farão logon como root ou precisarão fazer isso. No entanto, é
simples habilitar a conta root. O Mac OS X oferece suporte para vários sistemas de
arquivos, incluindo HFS+ (Mac OS Extended), UFS (BSD Standard), NFS (padrão da
indústria para sistemas de arquivos em rede, ISO 9660 (sistema de arquivos CD-
ROM), MS-DOS, SMB, (Windows padrão de compartilhamento de arquivos), AFP
(padrão de compartilhamento de arquivos do Mac OS) e UDF. O suporte para essa
multiplicidade de sistemas de arquivos é realizado por meio do uso de um sistema
de arquivos virtual. O formato HFS+ fornece recursos modernos bastante padrão,
como permissões de arquivo, nomes de arquivo longos, Unicode, links físicos e
simbólicos e tamanhos de disco grandes. O Mac OS X também fornece um recurso
incomum e útil implementado por "códigos de tipo" e "códigos de criação" que
anexam um código ao ID do arquivo que identifica o programa que o criou. Se o
usuário instruir o sistema a abrir um arquivo que foi criado em um programa
específico, o arquivo será aberto automaticamente nesse aplicativo (um
documento .txt criado no OpenOffice será aberto no OpenOffice em vez do
TextEdit). A utilidade desse recurso é um pouco limitada, no entanto, pelo fato de
que nenhum outro sistema operacional implementa esse recurso. (Apple KP 2003)

Conclusão
Discutimos, resumidamente, alguns dos recursos mais essenciais do sistema
operacional Mac OS X. Começamos com uma introdução às estruturas de dados no
Mac OS X, discutimos a implementação e gerenciamento de threads, exclusão
mútua no Mac OS e comunicação entre objetos. Também discutimos o
gerenciamento de memória do Mac OS e o sistema de arquivos do Mac OS. Deve
ser visto a partir desta discussão, que o Mac OS é fortemente dependente de
abstrações de Mach para implementar funções de um sistema operacional
extremamente aberto e definido por aplicativos. As abstrações de Mach por si só, no
entanto, são bastante incompletas sem a interface para os componentes de nível
superior. Por exemplo, o algoritmo de escalonamento Mach, se implementado
sozinho, resultaria em um escalonamento de execução quase completamente cego
com pouca visão das prioridades do usuário ou do desenvolvedor. Mach é cego de
propósito - ele é projetado para permitir que componentes em um nível mais alto
tomem decisões. O objetivo do Mach é fornecer um ambiente unificado onde essas
decisões possam ser aplicadas de maneira consistente e livre de conflitos. O Mac
OS X é provavelmente a extensão mais completa do kernel Mach desenvolvida até
hoje. A parte BSD do kernel (especialmente na definição de pthreads e processos) e
as APIs fornecidas pelo Mac OS X fornecem um contexto altamente versátil para
acessar e direcionar o kernel Mach.

Referências
(Silberschatz et al. 2 2003)
Silberschatz et al. 2003, Galvin & Gagne. (2003) "Operating System Concepts Sixth
Edition." Appendix B. John Wiley & Sons, Inc. URL:
www.bell-labs.com/topic/books/os-book/mach-dir/mach.pdf.

(Apple 2 2003)
Apple Computer, Inc.” (2003). “Apple’s Mac OS X Adoption Soars With
More Than 5 Million Users and 5,000 Native Applications.” URL:
http://www.apple.com/pr/library/2003/jan/07macosx.html

Mesa, Andy. (1998). “Apple History Timeline.” URL:


http://applemuseum.bott.org/sections/history.html

Garfinkel, Simon & Mahoney, Michael. (2002). “Steve Jobs and the


History of Cocoa, Part Two.” URL:
http://www.macdevcenter.com/pub/a/mac/2002/05/10/cocoa_history_two.html

(Apple 3 2003)
Apple Computer, Inc. (2003). “Mac OS X System Architecture.” URL:
http://developer.apple.com/macosx/architecture/index.html

Glaser, Richard & Reynolds, James. (2003). “Mac OS X History &


Terminology.” URL:
http://www.macos.utah.edu/movies/short_courses/022403_osx_hist&tech.pdf

(Apple 2003)
Apple Computer, Inc. (2003). “System Overview.” URL:
http://developer.apple.com/documentation/MacOSX/Conceptual/
SystemOverview/

(Silberschatz et al. 2003)


Silberschatz et al. 2003, Galvin & Gagne. (2003) "Operating System Concepts Sixth
Edition." John Wiley & Sons, Inc. ISBN 0-471-25060-0

(Apple KP 2003)
Apple Computer, Inc. (2003). "Inside Mac OS X: Kernel Programming." URL:
http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/

(Apple 2001)
Apple Computer, Inc. (2001). "Threading Architectures." URL:
http://developer.apple.com/technotes/tn/tn2028.html

Rashid, Tevanian, Young, Golub, Baron, Black, Bolosky & Chew. (1987) "Machine-
Independent Virtual Memory Management for Paged Uniprocessor and
Multiprocessor Architectures" URL: www.cs.berkeley.edu/~brewer/cs262/mach-
vm.pdf

Glaser, Richard. (2001). “Mac OS X: History.” URL:


http://www.macos.utah.edu/Documentation/macosx/history/
mac_osx_history.html

Você também pode gostar