O SO do TINI

O SO do TINI está abaixo da camada do ambiente de execução. Ele é responsável pelo gerenciamento de todos os recursos do sistema, incluindo acesso a memória, escalonamento de múltiplos processos e execução de threads (SUN, 2004), e interage com componentes

de hardware internos e externos. Apesar do SO ser um corpo de código complexo que desempenha muitas tarefas independentes, ele é razoavelmente bem representado pela soma dos três seguintes elementos majoritários:

• _{Escalonamento de processos e threads;} • Subsistema de gerenciamento de memória;

• Subsistema de gerenciamento de I/Os.

Os escalonadores - o SO contém ambos os processos e módulos escalonadores de threads que guiam a execução de código a nível de aplicativo. Os escalonadores são executados por um dos timers do microcontrolador que gera uma interrupção de alta prioridade a cada milissegundo. As rotinas do serviço de interrupção do timer (interrupt service routine-ISR) também executam ou inicializam as seguintes tarefas:

• Atualiza o contador de tempo do sistema a cada milissegundo;

• Executa o escalonador de threads a cada 2 milissegundos;

• Executa os módulos de drivers dos dispositivos a cada 4 milissegundos;

• Executa o escalonador de processos a cada 8 milissegundos.

Os processos são escalonados pelo escalonamento round robin (LIU, 2000). Cada

processo é executado em intervalos de tempo de 8 milissegundos. Após expirar o tempo do intervalo, o processo é enviado para o m de uma la de processos ativos que esperam seu retorno para execução de outro intervalo de tempo. Quando existem múltiplos processos no sistema, um único processo pode utilizar quase todos os recursos, desde que, exista apenas um processo ativo competindo pelo tempo de execução. Cada processo tem seu próprio escalonador de threads operando independentemente. Os threads a nível nativo são corporativos, cada thread voluntariamente cede o controle da CPU. Entretanto, para

o caso de aplicativos Java, thread são preemptados devido a JVM assegurar que cada thread cede a CPU depois de 2 milissegundos. Threads também são escalonados pelo escalonamento round-robin.

O subsistema de gerenciamento de memória - desempenha as seguintes tarefas:

• _{Aloca memória da pilha para ambos os processos do sistema e Java;} • O gc (garbage collector) é gerado automaticamente pelos processos Java;

• Gerência de arquivos do sistema.

Na Figura 3.2 é mostrado o segmento de dados que contém toda memória rápida de leitura escrita usada pelo ambiente de execução. A porção de memória da área do sistema para o m do segmento de dados é chamada pilha. A pilha representa a capacidade de memória do sistema. O acesso à pilha é controlado por um conjunto central de rotinas de alocação de memória. A operação básica dessas rotinas é muito similar à operação malloc de C. Uma exceção ocorre quando muitas operações de alocação de memória limpam todos os bytes de um bloco de memória alocado para 0 antes de retornar o bloco para o chamador. Muitos blocos de memória são alocados da pilha em benefício de novas operações executadas pela JVM ou por operações do sistema de arquivos. Raramente existem blocos de memória livres explicitamente. Isto é verdade devido a maioria da memória ser consumida pelas tarefas do sistema e de toda memória consumida pelo JVM em suporte a aplicativos Java. Memória é liberada pelo gc que ca executando como um processo separado do sistema. O processo gc é criado quando o sistema é ligado. Ele existe apenas em processos não-Java que são sempre criados. Sujeito normalmente à condicional de memória, o processo gc passa a maioria do tempo em estado inativo. Quando o gc, ou qualquer outro processo, estiver inativo ele não consome tempo de processamento. Ele é executado em uma das três maneiras:

• Um aplicativo invoca explicitamente o método gc denido na classe Java.lang.System;

• Uma nova operação reduz a quantidade de memória a níveis abaixo de 64 kilobytes;

• Um processo Java termina.

Quando o gc executa, ele não limpa o lixo da pilha inteira. Ele limpa apenas o lixo criado pelo processo que o executou. Quando o processo termina, toda memória consumida pelo processo, incluindo aquela mantida pelos objetos e estrutura interna da JVM é liberada.

Subsistema de I/Os - Os subsistemas de I/Os são divididos em duas categorias: I/Os em rede e I/Os não em rede. I/Os em rede, aqui referidos, são estritamente os I/Os

para grandes redes mundiais TCP/IP. Redes CAN e 1-wire, embora sejam tecnologia de rede não são caracterizadas como I/Os em redes.

O TCP/IP e o gerenciador de I/Os são implementados como processos kernel indepen- dentes. Estes processos são guiados por um sistema temporizado de 4 milissegundos. O gerenciador de I/Os controla todos os dispositivos não em rede. Pedidos de I/Os gerados por códigos de aplicativos passam todos pelo gerenciador de I/Os que os direcionam apro- priadamente. Certos pedidos de I/Os são enviados diretamente ao hardware do dispositivo conectado. Por exemplo, não existem drivers embutidos para comunicação com disposi- tivos arbitrários conectados à expansão do barramento paralelo. Neste caso, o aplicativo Java é responsável pelo gerenciamento de todos os detalhes de baixo nível da comunicação com o dispositivo.

O protocolo TCP/IP é um dos maiores blocos de código nativo do ambiente de ex- ecução. Ele fornece muitos recursos de rede encontrados em plataformas maiores e é sucientemente rico em funcionalidades para suportar a implementação total do pacote

Java.net. O protocolo suporta múltiplas interfaces de rede, incluindo Ethernet, para LANs (Local Area Networking) de alta velocidade e PPP (Point-to-Point Protocol) so- bre um link serial para rede dial-up remota usando um modem analógico. A interface Ethernet é gerenciada por um driver separado que desempenha toda comunicação com o controlador Ethernet. O PPP é um pouco diferente, ele atualmente conta com um driver para porta serial de baixo nível para entregar mensagens à rede pela porta física de comunicação.