Sistemas operacionais

Get Started. It's Free
or sign up with your email address
Rocket clouds
Sistemas operacionais by Mind Map: Sistemas operacionais

1. Sistemas de alocação de arquivos

1.1. FAT

1.1.1. sistema criado no MS-DOS e depois utilizado no Windows. Usa listas encadeadas, tem um limite de área utilizável em partições de 2 GB, caracteriza-se por um baixo desempenho no acesso e armazenamento.

1.2. FAT32

1.2.1. igual ao FAT no que diz respeito a organização e desempenho, mas pode trabalhar com partições de até 2TB.

1.3. NTFS

1.3.1. NT File System, original da plataforma Windows NT/2000/XP. Opera com uma estrutura em árvore binária, oferecendo alto grau de segurança e desempenho

1.4. UNIX

1.4.1. Usa diretório hierárquico, com um raiz e outros diretórios subordinados. Neste Sistema Operacional todos os arquivos são considerados apenas como uma “seqüência” de bytes, sem significado para o Sistema. É responsabilidade da aplicação controlar os métodos de acesso aos arquivos. O UNIX utiliza também alguns diretórios padronizados, de exclusividade do Sistema.

1.5. Gerência de espaço livre

1.5.1. São três as formas de se implementar estruturas de espaços livres. Uma delas é através de uma tabela denominada mapa de bits, onde cada entrada da tabela é associada a um bloco do disco representado por um bit, que estando com valor 0 indica que o espaço está livre, e com valor 1 representa um espaço ocupado. Gasta muita memória, pois para cada bloco do disco há uma entrada na tabela

1.5.1.1. Alocação contígua

1.5.1.1.1. armazena o arquivo em blocos seqüencialmente dispostos no disco. O arquivo é localizado através do endereço do primeiro bloco de sua extensão em blocos. O principal problema neste tipo de alocação é a existência de espaço livre para novos arquivos, que deve ser contígua

1.5.1.2. Alocação encadeada

1.5.1.2.1. nesta modalidade o arquivo é organizado como um conjunto de blocos ligados logicamente no disco, independente de sua localização física, onde cada bloco possui um ponteiro para o bloco seguinte

1.5.1.3. Alocação indexada

1.5.1.3.1. esta técnica soluciona a limitação da alocação encadeada, no que diz respeito ao acesso, pois permite acesso direto aos blocos do arquivo. Isso é conseguido mantendo-se os ponteiros de todos os blocos do arquivo em uma única estrutura chamada bloco de índice.

1.5.2. Proteção de acesso

1.5.2.1. Senha de acesso

1.5.2.1.1. mecanismo de simples implementação, mas apresenta duas desvantagens: não é possível determinar quais os tipos de operação podem ser efetuadas no arquivo, e, se este for compartilhado, todos os usuários que o utilizam devem conhecer a senha de acesso.

1.5.2.2. Grupos de usuário

1.5.2.2.1. é muito utilizada em muitos Sistemas Operacionais. Consiste em associar cada usuário a um grupo. Os grupos são organizados logicamente com o objetivo de compartilhar arquivos e diretórios no disco. Este mecanismo implementa três níveis de proteção: OWNER (dono), GROUP (grupo) e ALL (todos).

1.5.2.3. Lista de controle de acesso

1.5.2.3.1. é uma lista associada ao arquivo onde são especificados quais os usuários e os tipos de acesso permitidos. O tamanho dessa estrutura pode ser bastante extenso se considerarmos que um arquivo pode ser compartilhado por vários usuários. Além deste problema, há o inconveniente de se fazer acesso seqüencial à lista toda vez que um acesso é solicitado.

2. GERÊNCIA DE SISTEMAS DE ARQUIVOS

2.1. É como o Sistema organiza logicamente os arquivos. Contém entradas associadas aos arquivos, com as informações de localização, nome, organização e outros atributos

2.1.1. Nível único

2.1.1.1. é a implementação mais simples de uma estrutura de diretórios, onde existe um único diretório contendo todos os arquivos do disco. É muito limitado, não permitindo a criação de arquivos com o mesmo nome.

2.1.2. Diretório pessoal

2.1.2.1. Evolução do modelo anterior, permite a cada usuário ter ser “diretório” particular, sem a preocupação de conhecer os outros arquivos do disco. Neste modelo há um diretório “master” que indexa todos os diretórios particulares dos usuários, provendo o acesso a cada um.

2.1.3. Múltiplos níveis (ÁRVORE)

2.1.3.1. É o modelo utilizado hoje em dia em quase todos os Sistemas Operacionais. Nesta modalidade cada usuário pode criar vários níveis de diretórios (ou sub-diretórios), sendo que cada diretório pode conter arquivos e subdiretórios. O número de níveis possíveis depende do Sistema Operacional.

2.2. Estrutura de Diretórios

3. Um computador para se adequar ao usuário, deve possuir não apenas dois níveis, mas quantos forem necessários para seu bom funcionamento.

4. O que é um Sistema Operacional

4.1. Um sistema operacional é um conjunto de rotinas executadas pelo processador, de forma semelhante aos outros programas utilizados.

5. FUNÇÕES BÁSICAS

5.1. O sistema operacional serve de interface entre os usuários e os recursos disponíveis no sistema computacional, com isso, podemos estabelecer que ele deve: • Fornecer uma interface com o usuário; • Gerenciar a operação dos dispositivos de hardware do computador; • Gerenciar e manter o sistema de arquivos; • Dar suporte aos programas que são executados.

5.1.1. O sistema operacional é quem fornece a interação entre você e o seu computador. Você manipula o teclado e o mouse.

6. MÁQUINA DE CAMADAS

6.1. O sistema computacional composto somente de hardware, tem pouca utilidade. É através do software que o usuário interage com a máquina. Uma operação efetuada pelo software pode ser implementada no hardware, enquanto uma instrução executada pelo hardware pode ser simulada via software. Tanto o hardware quanto o software são logicamente equivalentes, interagindo de uma forma única para o usuário.

6.1.1. O computador pode ser compreendido como uma máquina de camadas em dois níveis: hardware (nível 0) e software (nível 1). Essa visão em camadas é chamada de máquina virtual

6.1.1.1. Aplicações Utilitários Sistema Operacional Linguagem de Máquina Microprogramação Circuitos Eletônicos

7. CONCORRÊNCIA

7.1. Sistemas Operacionais podem ser vistos como um conjunto de rotinas executadas de forma concorrente e ordenada. O processador pode executar instruções ao mesmo tempo, como por exemplo, operações de entrada e saída, permite que diversas tarefas sejam executadas concorrentemente. O conceito de concorrência é o princípio básico para o projeto e a implementação dos sistemas multiprogramados.

7.1.1. Sistemas Monoprogramáveis Multiprogramaveis

7.1.1.1. sistemas monoprogramaveis

7.1.1.1.1. existe bastante desperdício de processador, o tempo de espera entre uma instrução e outra é longo se comparada com a velocidade do processador em executar as instruções.

7.1.1.2. sistemas multiprogramaveis

7.1.1.2.1. vários programas podem estar residentes em memória, concorrendo pela utilização do processador. Dessa forma, enquanto um programa executa operações de entrada e saída, outros podem utilizar o processador. A memória se torna mais eficiente.

7.1.1.3. Interrupções e Exceções

7.1.1.3.1. Durante a execução de um programa podem ocorrer alguns eventos inesperados, ocasionado um desvio forçado no seu fluxo de execução. Estes tipos de eventos, são conhecidos por Interrupção ou Exceção e pode ser consequência da sinalização de algum dispositivo de hardware externo ao processador ou da execução de instruções do próprio programa.

7.1.2. Operações de Entrada/Saída

7.1.2.1. Em sistemas mais primitivos, a comunicação entre a UCP e os periféricos era controlada por um conjunto de instruções especiais, denominadas instruções de entrada / saída, executadas pela própria UCP. Essas instruções continham detalhes específicos de cada periférico, como quais trilhas e setores de um disco deveriam ser lidos ou gravados em determinado bloco de dados.

7.1.2.2. A operação de E/S controlada por interrupção é muito mais eficiente que a operação de E/S controlada por programa, já que elimina a necessidade de a UCP esperar pelo término da operação, além de permitir que várias operações de E/S sejam executadas simultaneamente.

7.1.3. Buffering

7.1.3.1. A técnica de buffering consiste na utilização de uma área de memória para a transferência de dados entre os periféricos e a memória principal denominada buffer. O buffering veio permitir que, quando um dado fosse transferido para o buffer após uma operação de leitura, o dispositivo de entrada pudesse iniciar uma nova leitura.

7.1.4. Spooling

7.1.4.1. A técnica de spooling (simultaneous peripheral operation on-line) foi introduzida no final dos anos 50 para aumentar a produtividade e a eficiência dos sistemas operacionais. Naquela época, os programas dos usuários eram submetidos um a um para processamento pelo operador. Como a velocidade de operação dos dispositivos de entrada/saída é muito lenta se comparada à do processador, era comum que a UCP ficasse ociosa à espera de programas e dados de entrada ou pelo término de uma impressão.

7.1.5. Reentrância

7.1.5.1. Reentrância é a capacidade de um código de programa (código reentrante) poder ser compartilhado por diversos usuários, exigindo que apenas uma cópia do programa esteja na memória.

8. ESTRUTURA DOS SISTEMAS OPERACIONAIS

8.1. O sistema operacional é formado por um conjunto de rotinas (procedimentos) que oferecem serviços aos usuários do sistema e suas aplicações, bem como a outras rotinas do próprio sistema. Esse conjunto de rotinas é chamado núcleo do sistema ou Kernel (cérebro).

8.1.1. ➢tratamento de interrupções; ➢criação e eliminação de processos; ➢sincronização e comunicação de processos; ➢escalonamento e controle dos processos; ➢gerência de memória; ➢gerência do sistema de arquivos; ➢operações de entrada e saída; ➢contabilização e segurança do sistema.

8.1.1.1. System Calls

8.1.1.1.1. Uma preocupação que surge na grande maioria dos projetos de sistemas operacionais é a implementação de mecanismos de proteção ao núcleo do sistema e de acesso aos seus serviços. Caso uma aplicação, que tenha acesso ao núcleo, realize uma operação que o danifique, todo o sistema poderá ficar comprometido e inoperante.

8.1.1.2. Modos de Acesso

8.1.1.2.1. Existem certas instruções que não podem ser colocadas diretamente à disposição das aplicações, pois a sua utilização indevida ocasionaria sérios problemas à integridade do sistema. Suponha que uma aplicação deseja atualizar um arquivo em disco. O programa, por si só, não pode especificar diretamente as instruções que acessam seus dados. Como o disco é um recurso compartilhado, sua utilização deverá ser realizada unicamente pelo sistema operacional, evitando que a aplicação possa ter acesso a qualquer a qualquer área do disco indiscriminadamente, o que poderia comprometer a segurança do sistema.

8.1.1.3. Arquiteturas do núcleo

8.1.1.3.1. A arquitetura do sistema é bastante complexa e deve atender aos requisitos de confiabilidade, portabilidade, fácil manutenção, flexibilidade e desempenho. A estrutura do núcleo do sistema operacioanal, ou seja, a maneira como o código do sistema é organizado e o inter-realcionamento entre seus diversos dispositivos, pode variar conforme o projeto

8.1.1.4. Sistemas Monolíticos

8.1.1.4.1. Essa arquitetura pode ser comparada com uma aplicação formada por vários módulos que são compilados separadamentee depois unidos por links, formando um único programa, onde os módulos podem interagir livremente.

8.1.1.5. Sistemas em Camadas

8.1.1.5.1. Um sistema em camadas divide o sistema operacional em camadas sobrepostas. Cada módulo oferece um conjunto de funções que podem ser utilizadas por outros módulos. Módulos de uma camada podem fazer referência apenas a módulos das camadas inferiores.

8.1.1.6. Máquinas Virtuais

8.1.1.6.1. Um sistema computacional é formado por níveis, onde a camada de nível mais baixo, é o hardware, acima, está o sistema operacional. Esse modelo de máquina virtual, cria um nível intermediário entre o hardware e o sistema operacional, denomeinado gerência de máquinas virtuais. Este nível cria diversas máquina virtuais independentes, onde cada uma oferece uma cópia virtual do hardware, incluindo os modeos de acesso, interrupções, dispositivos de E/S, etc.

8.1.1.7. Arquitetura Microkernel

8.1.1.7.1. Uma tendência dos sistemas operacionais modernos é tornar o núcleo do sistema operacional o menor e mais simples possível. Para implementar esta idéia, o sistema é dividido em processos, sendo cada um responsável por oferecer um conjunto de serviços, como serviços de arquivos, serviços de criação de processos, serviços de memória, serviços de escalonamento, etc.

9. PROCESSO

9.1. O processo é a base para implantação de um sistema operacional multiprogramável. O processador executa instruções, sem distinguir qual programa se encontra em execução. A gerência de um ambiente multiprogramável é uma função exclusiva do sistema operacional, que deve controlar a execução dos diversos programas e o uso concorrente do processador. Um programa para ser executado, deve estar sempre ligado a um processo.

9.1.1. Estrutura do Processo

9.1.1.1. O processador foi projetado para executar as instruções a partir do ciclo de busca e execução. Imaginemos como os sistemas operacionais multiprogramáveis atendem os diversos usuários e ainda mantém informações a respeito dos vários programas executados ao mesmo tempo

9.1.1.1.1. O processo se trata de um programa em execução, só que em escalas mais mais amplas. Para que a concorrência entre os processos ocorra sem problemas, é necessário que as informações do programa interrompido sejam guardadas, para que quando volte a ser processado, nenhuma informação seja perdida. Todas informações importantes e necessárias à execução de um programa fazem parte de um processo.

9.1.2. O termo processo surgiu após a criação dos sistemas operacionais multiprogramáveis, sendo utilizado no lugar de tarefa ou job, por grande parte da literatura técnica.

10. THREAD

10.1. Até o final dos anos 70, os sistemas operacionais suportavam processos com apenas um thread (monothread), ou seja, um processo com apenas um programa fazendo parte de seu contexto. Em 1979, introduziu-se o conceito de processos “ligthweight” (peso leve), onde o espaço de endereçamento de um processo era compartilhado por vários programas. Porém, esta idéia não foi utilizada comercialmente, só na metade da década de 80, com a criação do sistema operacional Mach, ficou clara a separação entre os conceitos de processo e thread.

10.1.1. Ambiente Monothread

10.1.1.1. Em um ambiente monothread, um processo suporta apenas um programa em seu espaço de endereçamento. Neste ambiente, aplicações concorrentes são implementadas apenas com o uso de múltiplos processos independentes ou subprocessos.

10.1.1.1.1. problema a ser considerado é quanto ao compartilhamento do espaço de endereçamento. Como cada processo possui seu próprio espaço de endereçamento, a comunicação entre processos torna-se difícil e lenta, pois utiliza mecanismos como pipes, sinais, semáforos, memória compartilhada ou troca de mensagem.

10.1.2. Ambiente Multithread

10.1.2.1. Em um ambiente multithread, ou seja, com múltiplos threads, não existe a idéia de programas associados a processos, mas sim a threads. O processo, neste ambiente, tem pelo menos um thread em execução, mas pode compartilhar o seu espaço de endereçamento com inúmeros outros threads.

10.1.2.1.1. De forma simplificada, um thread pode ser definido como uma sub-rotina de um programa que pode ser executada de forma assíncrona, ou seja, executada paralelamente ao programa chamador. O programador deve especificar os threads, associando-os às subrotinas assíncronas. Assim, um ambiente multithread possibilita a execução concorrente de sub-rotinas dentro de um mesmo processo.

10.1.3. A grande diferença entre aplicações mono e multithread está no uso do espaço de endereçamento. Processos independentes e subprocessos possuem espaços de endereçamento individuais e protegidos, enquanto threads compartilham o espaço dentro de um mesmo processo. Isso permite que o compartilhamento de dados entre threads de um mesmo processo seja mais simples e rápido, se comparado a ambientes monothreads.

10.1.4. Programação Multithreads

10.1.4.1. O desenvolvimento de aplicações multithread não é simples, pois exige que a comunicação e o compartilhamento de recursos entre os diversos threads seja feito de forma sincronizada para evitar problemas de inconsistências e deadlock. Além das dificuldades naturais no desenvolvimento de aplicações concorrentes, o procedimento de depuração é bastante complexo.

10.1.4.1.1. Dependendo da implementação, a definição do numero de threads pode ser dinâmica ou estática. Quando a criação/eliminação é dinâmica, os threads são criados/eliminados conforme a demanda da aplicação, oferecendo grande flexibilidade. Já em ambientes estáticos, o número de threads é definido na criação do processo onde a aplicação será executada.

10.1.5. Arquitetura e Implementação

10.1.5.1. O conjunto de rotinas disponíveis para que uma aplicação utilize as facilidades dos threads é chamado de pacote de threads. Existem diferentes abordagens na implementação deste pacote em um sistema operacional, o que influenciará no desempenho, na concorrência e na modularidade das aplicações multithread.

10.1.5.1.1. Uma das grandes dificuldades para a utilização de threads foi a ausência de um padrão. Em 1995, o padrão POSIX P1003.1c foi aprovado e posteriormente atualizado para a versão POSIX 1003.4 a. Com este padrão, também conhecido como Pthreads, aplicações comerciais multithreading tornaram-se mais simples e de fácil implementação. O padrão Pthreads é largamente utilizado em ambientes Unix, como o Sun Solaris Pthreads e o DECthreads para Digital OSF/1.

10.1.6. Threads em Modo Usuário

10.1.6.1. Threads em modo usuário (TMU) são implementados pela aplicação e não pelo sistema operacional. Para isso, deve existir uma biblioteca de rotinas que possibilite a aplicação realizar tarefas como criação/eliminação de threads, troca de mensagens entre threads e uma política de escalonamento. Neste modo, o sistema operacional não sabe da existência de múltiplos threads, sendo responsabilidade exclusiva da aplicação gerenciar e sincronizar os diversos threads existentes.

10.1.6.1.1. Threads em modo usuário

10.1.7. Threads em Modo Kernel

10.1.7.1. Threads em Modo Kernel (TMK) são implementados diretamente pelo núcleo do sistema opeacional, através de chamadas a rotinas do sistema que oferecem todas as funções de gerenciamento e sincronização. O sistema operacional sabe da existência de cada thread e pode escaloná-los individualmente. No caso de múltiplos processadores, os threads de um mesmo processo podem ser executados simultaneamente

10.1.7.1.1. O grande problema para pacotes em modo kernel é o seu baixo desempenho. Enquanto nos pacotes em modo usuário todo tratamento é feito sem ajuda do sistema operacinal, ou seja, sem a mudança do modo de acesso (usuário-kernel-usuário), pacotes em modo kernel utilizam chamadas a rotinas do sistema e, conseqüentemente, várias mudanças no modo de acesso.

10.1.8. Threads em Modo Híbrido

10.1.8.1. A arquitetura de threads em modo híbrido combina as vantagens de threads implementados em modo usuário (TMU) e threads em modo kernel (TMK). Um processo pode ter vários TMKs, e por sua vez, um TMK pode ter vários TMUs. O núcleo do sistema operacional reconhece os TMKs e pode escaloná-los individualmente. Um TMU pode ser executado em um TMK, em um determinado momento, e no instante seguinte ser executado em outro.

10.1.8.1.1. O modo híbrido, apesar de maior flexibilidade, apresenta problemas herdados de ambas as implementações. Por exemplo, quando um TMK realiza uma chamada bloqueante, todos os TMUs são colocados no estado de espera. TMUs que desejam utilizar vários processos deve utilizar diferentes TMKs, o que influenciará no desempenho.

10.1.9. Scheduler Activations

10.1.9.1. Os problemas apresentados no pacote de threads em modo híbrido existem devido à falta de comunicação entre threads em modo usuário e em modo kernel. O modelo ideal deveria utilizar as facilidades do pacote em modo kernel com o desempenho e flexibilidade do modo usuário.

10.1.9.1.1. A maneira de alcançar um melhor desempenho é evitar as mudanças de modos de acesso desnecessárias (usuário-kernel-usuário). Caso um thread utilize uma chamada ao sistema que o coloque no estado de espera, não é necessário que o kernel seja ativado, bastando que a própria biblioteca em modo usuário escalone outro thread. Isto é possível porque a biblioteca em modo usuário e o kernel se comunicam e trabalham de forma cooperativa. Cada camada implementa seu escalonamento de forma independente, porem trocando informações quando necessário.

11. SINCRONIZAÇÃO E COMUNICAÇÃO ENTRE PROCESSOS

11.1. A criação dos sistemas operacionais multiprogramáveis foi o que tornou possível estruturar as aplicações de modo que partes diferentes do código pudessem ser executadas concorrentemente. Este tipo de aplicação foi denominada de aplicação concorrente.

11.1.1. Os processos de uma aplicação concorrente podem compartilhar recursos, como arquivos registros, dispositivos de E/S e áreas de memória. Este compartilhamento pode gerar situações indesejáveis, capazes de comprometer a execução das aplicações. Para evitar este tipo de problema, os processos devem ter suas ações sincronizadas, através de mecanismos oferecidos pelo sistema operacional.

11.1.1.1. Aplicações Concorrentes

11.1.1.1.1. Em aplicações concorrentes, pode ser necessário que os processos comuniquemse entre si. Esta comunicação pode ser implementada através de variáveis compartilhadas na memória principal ou trocas de mensagens. Mais uma vez, é necessário que haja sincronização entre a execução dos processos concorrentes.

11.1.1.2. Especificação de Concorrência em Programas

11.1.1.2.1. As primeiras notações para especificar uma concorrência em um programa foram os comandos FORK e JOIN.

11.1.1.3. Problemas de Compartilhamento de Recursos

11.1.1.3.1. quando dois ou mais processos compartilham um mesmo recurso, alguns mecanismos devem evitar que este tipo de problema ocorra (conhecidos como race conditions – condições de corrida).

11.1.1.4. Exclusão Mútua

11.1.1.4.1. Para que sejam evitados problemas desta natureza, onde dois processos manipulem o mesmo arquivo ou a mesma variável de memória simultaneamente, enquanto um processo estiver acessando determinado recurso, todos os outros que queiram acessar esse mesmo recurso deverão esperar. Isso se chama EXCLUSÃO MUTUA (Mutual Exclusion). A exclusão mútua deverá agir apenas sobre os processos que estão concorrendo em um determinado recurso.

11.1.1.5. Starvation

11.1.1.5.1. duas formas do sistema operacional determinar qual será a vez de quem. Ou por escolha aleatória ou por prioridades. Quando a escolha é aleatória, existirá a probabilidade de um processo nunca ser escolhido. Quando for uma escolha por prioridades, um processo de menor prioridade nunca receberá o acesso ao recurso, e ai este processo nunca executará sua rotina.

11.1.1.6. Sincronização condicional

11.1.1.6.1. ficará em estado de espera até que o mesmo esteja pronto. Existe o risco deste recurso nunca ficar pronto por já estar com problemas. Ai todo o sistema fica esperando o recurso resolver sua vida. Um exemplo disto é o caso do uso de Buffers para leitura e gravação de dados feita pelos processos. Uma possível falha na memória que impeça o acesso aos buffers e todo o sistema estará parado.

11.1.1.7. Soluções de Hardware

11.1.1.7.1. Desabilitação de interrupções

11.1.1.7.2. Instrução test-and-set

11.1.1.8. Soluções de software

11.1.1.8.1. Diversos algoritmos foram propostos na tentativa de implementar a exclusão mútua através de soluções de software. As primeiras soluções tratavam apenas da exclusão mútua para dois processos e, inicialmente, apresentavam alguns problemas. A evolução ocorreu até uma solução definitiva para a exclusão mútua para N processos.

11.1.1.9. Semáforos

11.1.1.9.1. O semáforo é uma variável que fica associada a um recurso compartilhado, indicando quando este está sendo acessado por um outro processo. Ela terá seu valor alterado quando o processo entra e quando sai da região crítica de forma que se um outro processo entrar em sua região critica ele possa checar antes este valor para saber se o recurso esta ou não disponível. Quando o processo tiver seu acesso impedido, ele será colocado em uma fila de espera associada ao semáforo aguardando sua vez de utilizar o recurso. Todos os processos da fila terão acesso ao recurso na ordem de chegada.

11.1.1.10. Monitores

11.1.1.10.1. são mecanismos de sincronização compostos de um conjunto de procedimentos, variáveis e estrutura de dados definidos dentro de um módulo cuja finalidade é a implementação automática da exclusão mútua entre seus procedimentos. Somente um processo pode estar executando um dos procedimentos do monitor em um determinado instante. Toda vez que um processo chamar um destes procedimentos, o monitor verifica se já existe outro processo executando algum procedimento do monitor. Caso exista, o processo fica aguardando a sua vez ate que tenha permissão para executá-lo.

11.1.1.11. Troca de mensagens

11.1.1.11.1. troca de mensagens é um mecanismo de comunicação e sincronização entre os processos, implementado pelo sistema operacional através de duas rotinas do sistema SEND e RECEIVE. A rotina SEND é a responsável pelo envio de uma mensagem para o processo receptor enquanto a rotina RECEIVE por receber a mensagem do processo transmissor. Tais procedimentos mesmo não sendo mutuamente exclusivos permitem a comunicação entre os processos e a sincronização entre eles, pois uma mensagem somente poderá ser lida depois de ter sido enviada e ela somente será envidada após a ocorrência de um evento.

11.1.1.12. Deadlock

11.1.1.12.1. O Deadlock existe em qualquer sistema multiprogramável. Dizemos que um processo está em Deadlock quando este para de responder porque está esperando por um evento que nunca ocorrerá. Esta situação é conseqüência do problema da exclusão mútua.

12. GERÊNCIA DO PROCESSADOR

12.1. Com o surgimento dos sistemas multiprogramáveis, onde múltiplos processos poderiam permanecer na memória e disputar o uso de um único processador, a gerência do processador tornou-se uma das atividades mais importantes em um sistema operacional

12.1.1. Critérios de escalonamento

12.1.1.1. Utilização do processador

12.1.1.1.1. corresponde a uma taxa de utilização, que na maioria dos sistemas varia entre 30 e 90%. Uma utilização abaixo dos 30% indicaria um sistema ocioso, com carga de processamento baixa, enquanto uma taxa de utilização acima dos 90% pode indicar um sistema bastante carregado, próximo da sua capacidade máxima (em alguns casos tal situação pode levar a um crash – travamento do sistema).

12.1.1.2. Throughput

12.1.1.2.1. é o número de processos executados em um determinado intervalo de tempo. Quanto maior o throughput, maior o número de tarefas executadas em função do tempo. A maximização do throughput é desejada na maioria dos sistemas.

12.1.1.3. Tempo de Processador

12.1.1.3.1. é o tempo que um processo leva no estado de execução, durante seu processamento. As políticas de escalonamento não interferem neste parâmetro, sendo este tempo função apenas do código executável e da entrada/saída de dados.

12.1.1.4. Tempo de Espera (pela CPU)

12.1.1.4.1. é todo o tempo que o processo permanece na fila de pronto, aguardando a liberação da CPU para ser executado. A redução deste tempo de espera é desejada pela maioria das políticas de escalonamento.

12.1.1.5. Tempo de Turnaround

12.1.1.5.1. é o tempo total que o processo permaneceu no sistema, desde sua criação até o momento em que é encerrado. São contados os tempos de alocação de memória, espera na fila de pronto e interrupção (E/S).

12.1.1.6. Tempo de Resposta

12.1.1.6.1. é o tempo decorrido entre uma requisição ao sistema e o instante em que a resposta começa a ser exibida. Em sistemas interativos, como aplicações on-line ou acesso à Web, os tempos de resposta devem ser da ordem de apenas poucos segundos.

12.1.2. Escalonamentos Não-Preemptivos e Preemptivos

12.1.2.1. não-preemptivos são aqueles onde o sistema operacional não pode interromper o processo em execução para retirá-lo da CPU.

12.1.2.1.1. escalonamentos não-preemptivos

12.1.2.2. preemptivos são caracterizados pela possibilidade de o sistema operacional interromper o processo em execução para retirá-lo da CPU e dar lugar a outro. Neste caso o processo retirado da CPU volta ao estado de pronto, onde permanece aguardando nova oportunidade de ocupar a CPU.

12.1.2.2.1. escalonamentos preemptivos

13. GERÊNCIA DE MEMÓRIA / MEMÓRIA VIRTUAL

13.1. Historicamente, a memória principal sempre foi vista como um recurso escasso e caro. Uma das maiores preocupações dos projetistas foi desenvolver sistemas operacionais que não ocupassem muito espaço de memória e, ao mesmo tempo, otimizassem a utilização dos recursos computacionais. Mesmo atualmente, com a redução do custo e o aumento considerável da capacidade da memória principal, seu gerenciamento é dos fatores mais importantes no projeto e implementação dos sistemas operacionais.

13.1.1. Funções

13.1.1.1. Geralmente, os programas são armazenados em memórias secundárias, de uso permanente e não voláteis, como discos ou fitas. Como o processador somente executa o que está na memória principal, o sistema operacional deve sempre transferir programas da memória secundária para a principal antes de serem executados. Como o tempo de acesso às memórias secundárias é muito superior ao tempo de acesso à memória principal, o sistema operacional deve buscar reduzir o número de operações de E/S (acessos à memória secundária) a fim de não comprometer o desempenho do sistema.

13.1.2. Alocação Contígua Simples

13.1.2.1. Este tipo de alocação foi implementado nos primeiros sistemas operacionais, embora ainda nos dias de hoje esteja presente em alguns sistemas monoprogramáveis. Nesse modelo, a memória principal é dividida em duas partes, uma para o sistema operacional e a outra para o programa do usuário. Dessa forma, o programador deve desenvolver suas aplicações preocupado apenas em não ultrapassar o espaço de memória disponível.

13.1.3. Segmentação de Programas

13.1.3.1. Na alocação contígua simples todos os programas estão limitados ao tamanho da memória principal disponível para o usuário. Uma solução encontrada para o problema é dividir o programa em módulos, de modo que seja possível a execução independente de cada módulo, utilizando a mesma área de memória. A esta técnica dá-se o nome de segmentação ou overlay.

13.1.3.1.1. A definição das áreas de overlay é função do programador, através de comandos específicos da linguagem de programação utilizada.

13.1.4. Alocação Particionada Estática

13.1.4.1. Nos primeiros sistemas multiprogramáveis a memória era dividida em blocos de tamanho fixo, chamados partições.O tamanho dessas partições, estabelecido em tempo de inicialização do sistema, era definido em função do tamanho dos programas que executariam no ambiente.Sempre que fosse necessária a alteração do tamanho de uma partição, o sistema deveria ser inicializado novamente com uma nova configuração.

13.1.4.1.1. Inicialmente, os programas só podiam ser carregados e executados em apenas uma partição específica, mesmo que as outras estivessem disponíveis. Esta limitação se devia aos compiladores e linkeditores, que geravam apenas código absoluto. No código absoluto, todas as referências a endereços no programa são posições físicas na memória, ou seja, o programa só poderia ser carregado a partir do endereço de memória especificado no seu próprio código. A esse tipo de alocação de memória chamou-se alocação particionada estática absoluta.

13.1.5. Alocação Particionada Dinâmica

13.1.5.1. foi eliminado o conceito de partições de tamanho fixo. Nesse esquema, cada programa, ao ser carregado, utilizaria o espaço necessário à sua execução, tornando esse espaço a sua partição. Assim, como os programas utilizam apenas o espaço de que necessitam, no esquema de alocação particionada dinâmica o problema da fragmentação interna deixa de existir.

13.1.6. Estratégias de Alocação de Partição

13.1.6.1. Os sistemas operacionais implementam basicamente três estratégias para determinar em qual área livre um programa será alocado para execução. Essas estratégias tentam evitar ou diminuir o problema da fragmentação.

13.1.6.1.1. Best-fit

13.1.6.1.2. Worst-fit

13.1.6.1.3. First-fit

13.1.7. Swapping

13.1.7.1. É uma técnica aplicada à gerência de memória que visa dar maior taxa de utilização à memória principal, melhorando seu compartilhamento. Visa também resolver o problema da falta de memória principal num sistema.

13.1.8. Memória Virtual

13.1.8.1. é uma técnica sofisticada e poderosa de gerência de memória onde as memórias principal e secundária são combinadas, dando ao usuário a impressão de que existe muito mais memória do que a capacidade real de memória principal.

13.1.8.1.1. O conceito de memória virtual baseia-se em não vincular o endereçamento feito pelo programa aos endereços físicos da memória principal. Desta forma, o programa e suas estruturas de dados deixam de estar limitados ao tamanho da memória física disponível, pois podem possuir endereços vinculados à memória secundária, que funciona como uma extensão da memória principal.

13.1.9. Algoritmos de substituição de páginas

13.1.9.1. Os algoritmos de substituição de páginas têm o objetivo de selecionar os frames que tenham as menores chances de serem referenciados num futuro próximo. Caso contrário, o frame poderia retornar diversas vezes para a memória real, provocando excesso de page faults.

13.1.9.1.1. algoritmo ótimo

13.1.9.1.2. Algoritmo aleatório

13.1.9.1.3. Algoritmo FIFO (first in, first out)

13.1.9.1.4. Algoritmo LFU (least frequently used)

13.1.9.1.5. Algoritmo LRU (least recently used)

13.1.9.1.6. Algoritmo NRU (not recently used)

14. GERÊNCIA DE SISTEMAS DE ARQUIVOS