A Deadlock Case in Minix3: Considerations about Performance and Reliability

Tamanho: px
Começar a partir da página:

Download "A Deadlock Case in Minix3: Considerations about Performance and Reliability"

Transcrição

1 A Deadlock Case in Minix3: Considerations about Performance and Reliability J. Kinoshita, H. T. Omoto, P. d A. F. F. de S. Barbuda and W. L. Neto Abstract In 2006, professor Tanenbaum released Minix3 with a new book [15] and papers [14, 9, 8] supporting that drivers running as processes in user mode made Minix, a microkernel operating system, more reliable than monolithic operating systems. We tested Minix3 in a operating system course at University of São Paulo University and unfortunately, we were able to deadlock the system after inserting a bug in a driver. Based on this problem, we make some considerations about performance and reliability in Minix3. O Keywords Minix, Operating Systems, Microkernel. I. INTRODUÇÃO S 1 PROCESSADORES atuais possuem basicamente dois modos de operação: kernel (ou supervisor) e usuário. No modo kernel, o processador tem todo o controle da máquina, podendo executar instruções que fazem operações de I/O, manipulam ponteiros de pilhas (do kernel ou do usuário), acessam estruturas de dados que guardam o estado da máquina quando os processos são chaveados e ainda, acessam estruturas que cuidam do gerenciamento da memória virtual, atribuindo regiões de memória a processos. No modo usuário, o processador tem uma visão restrita da máquina. Por exemplo: se uma dada instrução tentar acessar I/O ou memória fora de sua região permitida então ocorrerá uma exceção. O processador passa do modo usuário para o kernel sempre que atende uma exceção que pode ser uma interrupção de hardware, erros (ex: divisão por zero) e interrupções de software (traps). O processador passa do modo kernel para o modo usuário ao termino da execução da exceção. A troca de modos causa um grande overhead (tempo gasto no chaveamento ao invés de se executar o aplicativo) pois em cada troca é necessário salvar ou recuperar os estados dos processos, alterar todo o cache de memórias, etc. A grande diferença entre os sistemas operacionais monolíticos e o microkernel é a quantidade de código que roda em modo kernel ou em modo usuário quando o sistema operacional responde a uma chamada de sistema: o microkernel advoga que quanto menos código rodar no kernel, melhor enquanto que nos sistemas monolíticos todo o tratamento é executado no modo kernel. O Minix é um 1 J. Kinoshita, Universidade de São Paulo (USP), São Paulo, São Paulo, Brasil, H. T. Omoto, Universidade de São Paulo (USP), São Paulo, São Paulo, Brasil, F. F. de S. Barbuda, Universidade de São Paulo (USP), São Paulo, São Paulo, Brasil, W. L. Neto, Universidade de São Paulo (USP), São Paulo, São Paulo, Brasil, sistema operacional microkernel e foi criado pelo prof. Andrew Tanenbaum para fins didáticos; mas ao mesmo de forma inovadora porque geralmente eles são monolíticos, como o Windows, Linux, FreeBSD e Solaris. Um sistema operacional monolítico é visto pelos programas aplicativos como um conjunto de rotinas, conhecidas como system calls (chamadas de sistema), que são executadas em modo kernel (passam a executar em modo kernel através das interrupções de software / trap). Por exemplo: leitura de bytes de um arquivo, alteração de senha, leitura do relógio. Em um sistema operacional microkernel como o Minix, o sistema operacional também tem como objetivo fornecer as mesmas system calls com a diferença de que boa parte das operações não é executada em modo kernel e sim no modo usuário. O microkernel não tem mais a responsabilidade de oferecer system calls e sim, a de oferecer serviços muito mais simples como send e receive que permitem a troca de mensagens entre os processos. A system call será trata por processos usuários rodando fora do kernel. No caso do Minix, dois processos que tratam das system calls são o gerenciador de arquivos FS (File System Manager) e o gerenciador de processos PM (Process Manager no Minix3, antes chamado de gerenciador de memória Memory Manager nos Minix1-2). O FS trata de system calls como o read e write e o PM de system calls como o fork e exit. Quando um processo aplicativo envia uma mensagem solicitando a system call read ao FS é gerado uma interrupção de software (trap). O FS troca diversas mensagens com outros processos, notoriamente os drivers, para que o read seja executado. O argumento em favor do sistema microkernel que quanto menos código rodar em modo kernel, menos erros fatais tendem a ser cometidos. Portanto, um sistema operacional microkernel tende a ser mais robusto porque ele está menos sujeito a erros por parte do programador. O argumento é semelhante a dar prefêrencia por usar uma máquina como usuário normal ao invés de usar como "root" (administrador do sistema). Quanto mais poder se tem, mais abuso pode se cometer. A idéia é dar poder somente quando estritamente necessário. Neste artigo, vamos argumentar que isso é parcialmente verdadeiro. É verdade que o código executado no microkernel é mais robusto do que o código executado no kernel de um sistema operacional monolítico; porém essa robustez não deveria ser comparada dessa forma. A comparação deve ser feito quanto à resposta às system calls. Por exemplo, é correto afirmar que o sistema microkernel é mais robusto comparando o fato de que ele não trava ao enviar

2 mensagens (atividade básica do microkernel) enquanto que o sistema monolítico trava ao escrever milhares de bytes em um arquivo (atividade básica do sistema operacional monolítico, mas muito mais complexa). Existe uma queda de desempenho em um sistema operacional microkernel [14] devido a diversas trocas de mensagens entre processos. Cada mensagem exisge que o sistema troque de modo kernel para modo usuário e viceversa, o que causa um overhead significativo. Uma estrutura de dados importante é a tabela de processos. Essa tabela contém informações sobre cada processo e os recursos a ele alocados como memória e arquivos abertos. Assim, uma parte da tabela de processos é manipulada pelo gerenciador de processos PM, pelo gerenciador do sistema de arquivos FS e pelo microkernel. Se um processo termina, é necessário que diversos processos se comuniquem entre si para que a tabela de processos distribuída se mantenha consistente. Assim, é fácil perceber que um sistema microkernel possui um desempenho inferior a um sistema monolítico. A queda de desempenho no Minix3 é maior que em outras versões [9] porque na nova versão 3, os drives são processos em modo usuário. Desse modo, é necessário que eles enviem mensagens ao kernel solicitando a entrada ou saída; pois essas operações (in e out no microprocessador x86) são privilegiadas. Em Maio de 2006, o professor Tanenbaum, autor do Minix [15], e outros autores publicaram o artigo: Can We Make Operating Systems Reliable and Secure?. Segundo o artigo a resposta é sim, e o caminho é o Minix3. O artigo defende o microkernel, e em especial, que os drivers devam ser colocados no espaço de usuário, rodando como processos de usuário. Isso porque se ocorrerem problemas nos drivers, então, o sistema poderá detectar o problema e reinicializar o driver. De acordo com [14]: Among the other specific features aimed at improving reliability, the most crucial is the self-healing property. If a driver does a store through an invalid pointer, gets into an infinite loop, or otherwise misbehaves, the reincarnation server will automatically replace it, often without affecting running processes. While restarting a logically incorrect driver will not remove the bug, in practice subtle timing and similar bugs cause many problems, and restarting the driver will often repair the system. In addition, this mechanism allows recovery from failures that are caused by attacks, such as the ping of death which can crash a computer by sending it an incorrectly formatted IP packet. (ênfase nossa). Em um curso de sistemas operacionais baseado em [15] resolvemos testar a capacidade do Minix de se recuperar no caso de drivers mal escritos; ou seja, a de testar a propriedade de se auto recuperar (self-healing property). Introduzimos um loop infinito em um driver para observar como o sistema se recuperava. Dependendo onde o loop infinito era inserido, o sistema não se recuperava; pelo contrário, todo o sistema travava, isto é, a shell travava e o usuário ficava impossibilitado de dar qualquer comando, mesmo o shutdown. Na seção II. mostramos como o Minix3 foi utilizado em um curso de sistemas operacionais e a proposta de vários projetos que nos possibilitaram estudar um deadlock decorrente do loop infinito em um driver. Isso foi inesperado porque estávamos apenas testando a veracidade da afirmação em [14]. Na seção III., apresentamos o estudo do motivo pelo qual o sistema não se recuperou do erro do loop infinito; ou seja, o motivo pelo qual o sistema entrou em deadlock. Por fim, na seção IV., questionamos se a queda de desempenho em um sistema microkernel é compensada pela robustez adicional ([14, 9, 8]). II. O MINIX EM NOSSO CURSO DE SISTEMAS OPERACIONAIS Existem diversas formas de se apresentar um sistema operacional em um curso de sistemas operacionais. O sistema operacional pode ser real (ex: Minix) ou simulado (ex: nachos que roda em uma máquina virtual MIPS) [2]. Alguns cursos de sistemas operacionais são apenas teóricos e não apresentam o código de um sistema operacional, mas [5] argumenta a importância do aprendizado experimental citando John Dewie (a educação genuína vem pela experiência), Lewin (o aprendizado decorre da participação ativa) e Piaget (o aprendizado decorre da interação entre o indivíduo e o ambiente). Em nossa própria experiência de ensino de sistemas operacionais, um aluno expressou que colocar a mão na massa fez a grande diferença no curso, pois de resto ele podia aprender lendo o livro-texto adotado [15]. Vamos nos restringir a discutir duas possíveis alternativas para um curso de sistemas operacionais: o uso do Minix e o uso do Linux. Entre o Minix e o Linux (ou mesmo o freebsd) optamos pelo Minix porque é muito mais simples, didático, e responde às system calls do padrão POSIX. O Minix tem sido usado em diversos cursos de sistemas operacionais. Isso pode ser visto pelas ementas dos cursos ou mesmo por artigos que relatam as experiências de professores e alunos: [7, 6, 1, 10]. O Minix3 apresenta a interface gráfica com o X Windows, roda o compilador gcc e possui interface com a rede; isto é, o Minix3 é um sistema operacional que está muito próximo de um sistema mais desenvolvido como o Linux. Se usássemos o Linux para fins didáticos teríamos diversos problemas: seu código se altera com muito mais rapidez e não é didático. Por exemplo: o Linux foi portado para diversas máquinas (ex: Intel e ARM) e isso se reflete em seu código (ex: código assembly para Intel e ARM). O gerenciador de memória do Linux faz uso da memória virtual enquanto o do Minix é muito mais simples e não suporta memória virtual. Usar a memória virtual implica em se conhecer profundamente o microprocessador. Existem diversos sistemas de arquivos suportados pelo Linux, enquanto que o Minix suporta apenas um bem simples. O Minix possui um livro didático a ele associado, enquanto o Linux não. Assim, do ponto de vista de ensino de sistemas operacionais, o Minix é uma escolha melhor. Ao final de cada capítulo de [15], o professor Tanenbaum propõe exercícios para serem realizados no Minix, em geral, algumas modificações no código. Dado que o Minix evolui mais rápido que o livro, encontramos exercícios propostos que nem podiam ser resolvidos, pois a solução já estava implementada na nova distribuição do Minix. Além disso, não apreciamos seguir os exercícios do livro porque a maioria deles são muito

3 específicos e complexos, não permitindo que o aluno tenha uma visão de mais alto nível. Em nosso curso de sistemas operacionais, resolvemos propor os nossos próprios projetos. Um exemplo é monitorar as mensagens trocadas entre processos para se entender como o Minix funciona. Vários projetos já foram criados e passados aos alunos cobrindo diversas partes do Minix, em especial, os drivers. Esses exercícios são alterados de ano para ano com o objetivo de criar uma base de trabalhos que podem ser utilizados por alunos de turmas posteriores. Dentre vários exercícios, uma sequência deles nos levou a questionar a capacidade do Minix3 de se auto-recuperar. Essa sequência de exercícios (projetos realizados por diferentes equipes de alunos) consistiu em criar um driver, testá-lo e depois introduzir um erro no driver. Vários desses exercícios já eram propostos em turmas anteriores. A nossa expectativa ao introduzir o loop infinito no driver era que o Minix3 iria de fato se recuperar como diz o artigo [14]; porém dado que nossa expectativa foi frustrada e o Minix travou, então tivemos que analisar o motivo. Os alunos que participaram da analise do motivo é que estão presentes como coautores; porém referenciamos os trabalhos das outras equipes também. Em nosso curso de sistemas operacionais propomos os seguintes exercícios sobre drivers: 1. Acessar portas de entrada e saída fora da competência do driver. Por exemplo: o driver da impressora não deve ser capaz de acessar portas referente à porta serial. Resposta: Constatamos que o Minix3 não se comportava de forma esperada, pois, drivers podiam acessar portas de entrada e saída fora de sua competência. Acreditamos que esse problema será resolvido facilmente em versões futuras do Minix. 2. No caso do Linux (ou outros Unix's), um driver é um conjunto de rotinas que implementam funções padronizadas como read e write. No caso do Minix, um driver é um processo que fica em um loop infinito onde ele recebe uma mensagem (ex: DEV_READ para ler dados do dispositivo, etc.) e as trata. Ao final do tratamento, o driver envia a mensagem TASK_REPLY(ok) informando ao FS que o driver tratou do pedido. Crie um driver muito simples no Minix que apenas imprime mensagens quando recebe mensagens do FS (ex: imprime ao receber DEV_OPEN, DEV_CLOSE, etc.). O driver pode ser associado a /dev/teste. Declare /dev/teste associando um major e minor number e o código do processo associado ao driver. Use service para rodar o driver. Gere um relatório sobre isso. As mensagens que o driver deve responder são: DEV_OPEN (abrir o driver), DEV_CLOSE (fechar o driver) e DEV_WRITE (escrever no driver). Envie mensagens a /dev/teste como em: veja as mensagens que são recebidas e que são impressas pelo seu driver. Faça o driver imprimir a string que recebeu ( "lixo "). Resposta: Os alunos implementaram adequadamente o driver. Puderam constatar que ao realizar um comando na shell como: levavam o driver a imprimir o que acontecia como proposto no exercício. A resposta apresentada pelos alunos se encontra em [11]. 3. Crie um driver como especificado em 2). Teste o driver: Envie mensagens a /dev/teste como em: e veja a mensagem que é impressa pelo seu driver. Agora faça com que o driver, logo após imprimir a string que recebeu lixo" entre em um loop infinito simulando um problema no driver. De acordo com [14], o sistema deveria ser capaz de se auto-recuperar de um erro em um driver, porque o reincarnation server deveria automaticamente detectar a falha e retartar o driver. Verifique se a prioridade do driver está sendo alterada, decaindo a cada ping. Faça: Se de fato for verdade que o driver é restartado então uma nova mensagem será escrita na tela. Verifique isso. Resposta: No Minix3, o responsável pelo gerenciamento do filesystem é o processo FS (File System). Ele é o intermediário entre o aplicativo e o driver, ou seja, é responsável por atender às system calls dos processos aplicativos e mandar as mensagens corretas para os drivers. Os alunos fizeram a experiência colocando um loop infinito em uma posição do código do driver, verificando se o sistema se recuperava. O relatório está apresentado em [12]. Eles colocaram o loop infinito em diversas posições e constataram que em alguns casos o sistema funcionava de acordo com o previsto [14], ou seja, o driver era restartado e em outros casos não. Isso foi inesperado e criamos o próximo exercício. Os casos em que ele trava ocorrem quando o loop infinito impede que o driver responda TASK_REPLY(ok) ao FS. Nesse caso, o FS está bloqueado esperando pela mensagem de retorno. Em outros casos, quando o FS está desbloqueado então o sistema se auto recupera como previsto pelo artigo [14]. 4. Observamos que o driver com o loop infinito faz o Minix travar e suspeitamos que ele trava porque o FS fica bloqueado esperando uma resposta do driver que não chega. Dada a dificuldade de se analisar o que de fato levou o Minix travar, faça o FS imprimir mensagens criando os comandos fale e quieto. O comando fale faz o FS imprimir as mensagens que troca e o comando quieto volta o FS ao estado normal. Através das mensagens impressas, procure entender o motivo pelo qual ele trava em algumas situações quando o driver fica em loop infinito. Resposta: é apresentada na próxima seção. De fato, foi confirmado que o problema envolvia o FS que ficava bloqueado aguardando uma resposta do driver que não chegava devido ao loop infinito. Esse bloqueio levava

4 outros processos também a serem bloqueados e enfim tivemos o deadlock. Fizemos algumas alterações no relatório original apresentado que está em [4]. Esse problema foi resolvido através dos alunos co-autores desse artigo. III. O LOOP INFINITO EM UM DRIVER LEVA O MINIX A UM DEADLOCK A grande diferença entre o Minix3 e versões anteriores é que os drivers rodam em modo usuário e além disso, caso se detecte que um driver morreu, ele é reinicializado. O processo RS - Reincarnation Server - roda no mesmo nível que o FS e o PM em modo usuário. O objetivo é enviar um ping periodicamente aos drivers e, caso o driver não responda, então ele é reinicializado. Para um driver não nativo, deve-se dar um comando para que o RS realize os pings. Caso contrário, não há tratamento pelo RS. Para ativar a monitoração do driver é necessário o seguinte comando (na shell): service up /usr/sbin/driverteste dev /dev/driverteste period 3Hz O comando faz com que o RS mande o ping a cada 3 segundos. Alteramos o Minix com o objetivo de monitorar a troca de mensagens criando os comandos fale e quieto. Esses comandos foram implementados através de system calls que são tratadas pelo FS. O comando fale tem como parâmetro o pid do aplicativo de teste (que acionará a rotina de escrita do driver) de forma que: O FS imprima as mensagens recebidas pelo processo aplicativo. Se fôssemos imprimir todas as mensagens recebidas teríamos o computador com uma tela cheia de mensagens sem sentido. Ao implementar a monitoração das mensagens, é preciso observar que a comunicação entre processos (usando o send, receive e sendrec) não utiliza o pid do processo origem ou destino e sim o seu endpoint (um número usado pelo Minix para identificar processos que fazem parte do tratamento das system calls). O FS imprima todas as mensagens enviadas a um driver com o objetivo de atender ao pedido do processo sendo monitorado. As mensagens são enviadas do FS aos drivers através de sendrec. O sendrec é uma forma de enviar mensagens no Minix onde o processo envia uma mensagem (send) e espera uma resposta (rec) [15]. Enquanto a resposta não vem, o processo (no caso, o FS) fica bloqueado. O fato do FS se comunicar dessa forma com o driver já é um indicativo de que problemas no driver podem acarretar problemas ao FS. A implementação dos comandos pode ser vista em [4]. Observamos que o RS possui um modo verbose (ativado através de uma flag) herdado de quando o Minix3 estava em desenvolvimento. A forma como esse modo pode ser ativado no Minix3 está em [4]. O problema do modo verbose é que não seleciona as mensagens como fizemos com o comando fale. Isso gera um fluxo relativamente alto de mensagens espúrias e não relacionadas ao nosso problema. Quando monitoramos o FS, executando o aplicativo de teste, observamos que o RS imprime uma mensagem dizendo que detectou um driver que não respondeu ao ping. Assim, monitoramos o sistema operacional através dos comandos fale/quieto e do modo verbose do RS. Na Fig. 1 apresentamos o código de teste usando a system call fala criada por nós que recebe como parâmetro o pid do processo a ser monitorado, no caso, o próprio pid do programa de teste. Figura 1. Programa "teste ". Faz o FS e driver apresentarem as mensagens trocadas ao escrever algo no driver. Na Fig. 2 apresentamos a saída ao rodar o programa de teste (em condições normais, sem loop infinito). O processo do usuário abre o driver. Isso acarreta uma mensagem que é enviada ao FS para tratar a system call open. O FS envia a mensagem DEV_OPEN para o driver (nesse exemplo, rodamos com /dev/teste, criado pelos alunos, e não com /dev/lp), o driver responde com TASK_REPLY para o FS. De forma semelhante ocorre a escrita (DEV_WRITE) e o fechamento do driver (DEV_CLOSE). Figura 2. Saída do programa teste. Em condições normais, a comunicação entre o programa teste, o FS e o driver pode ser representado na Fig. 3.

5 Embora tivéssemos drivers simples construídos por nós mesmos, resolvemos testar o loop infinito em um driver do próprio Minix por considerarmos que esses drivers são bem escritos e testados. Escolhemos o driver da impressora. Introduzimos um loop infinito na função de escrita do driver e constatamos que o Minix inteiro travava. Após monitorarmos e descobrirmos a causa do deadlock, fizemos uma alteração no driver da impressora, colocando o loop infinito de forma que o sistema pudesse se recuperar como previsto por [14]. Assim analisamos as duas possibilidades quando inserimos um loop infinito em um a driver: O Minix inteiro trava. RS detecta e reinicia driver. Figura 3. Fluxo de mensagens trocadas, Minix morre pois o FS fica esperando o TASK_REPLY(OK) do Driver acima o Minix morre na linha vermelha. O Minix inteiro trava caso o loop infinito seja inserido de forma que o driver não responda ao FS. Um exemplo é o que ocorre na Fig. 3. Caso o loop infinito seja inserido no driver na posição referente à linha vermelha, então o driver recebe a mensagem DEV_WRITE, mas deixa de responder a mensagem TASK_REPLY(OK) levando o Minix ao deadlock. Caso o driver responda ao FS então o Minix não trava. Utilizando as ferramentas fale/quieto e o modo verbose do RS pudemos chegar à conclusão de que o deadlock ocorre como na Fig. 4. Figura 4. deadlock O Minix3 entra em deadlock da seguinte forma: 1. O processo usuário requisita algum serviço (i.e. faz a system call write) ao FS. 2. Enquanto o processo fica bloqueado até receber uma resposta, o FS repassa a requisição ao driver do dispositivo adequado e o FS também fica bloqueado até receber resposta. 3. Enquanto isso, de tempos em tempos o RS (Reincarnation Server) manda mensagens DEV_PING a todos os dispositivos que ele monitora, de modo a verificar se estão funcionando. 4. Quando o RS percebe que o driver não responde ao DEV_PING (pois entrou em loop infinito), ele manda uma mensagem SIGKILL, tentando matá-lo. Esse sinal, assim como todos os outros, são tratados pelo PM - Process Manager. Como o RS usa uma system call normal para se comunicar com o PM, ele fica bloqueado até receber resposta, como qualquer outro processo também ficaria bloqueado esperando o retorno da system call. 5. O PM elimina o processo, libera sua memória e, por fim, tenta avisar o FS que o processo morreu. A função usada para isso, tell_fs, também bloqueia até receber a resposta do FS. 6. Porém, o FS também está bloqueado, esperando resposta do driver. O sistema inteiro trava. No passo 5, o PM está informando o FS que o driver vai ser finalizado para que o FS tome as medidas administrativas cabíveis (exemplo: limpar todos os arquivos associados ao processo que morre), mas o FS está travado pois está aguardando a resposta do driver para a requisição de write. Observamos que o PM se comunica com uma chamada bloqueante com o FS, o que faz com que o PM fique bloqueado esperando uma reposta do FS que já está bloqueado, e assim, temos o deadlock. O Reincarnation Server não restarta um driver em loop infinito em todas as situações. Descobrimos que, na verdade, ele é o principal causador do ciclo que trava o sistema, pois além de ser travado, causa o travamento do PM e, consequentemente, o fim do tratamento de mensagens pelo mesmo travando o sistema inteiro. Isto não deveria acontecer, pois o RS deveria garantir a confiabilidade do tratamento de erros como este. Sugerimos a seguinte alternativa para a correção deste problema: A detecção (pelo RS) que o FS está travado e, caso esteja, ele destrava o FS; Em seguida, manda o kill normalmente, pois o PM não será travado (ao realizar o tell_fs) por consequência do FS não estar também. Essa situação nos mostra que o RS, apesar de tratar o erro de maneira razoável, ainda possui pontos a ser melhorados. Ele, por possuir a função de tratar os erros e realizar a recuperação do sistema, não deveria esperar que nenhum outro servidor lhe enviasse uma resposta. Idealmente, o RS deveria supor que exista a possibilidade de outro servidor (como o FS) estar travado. Portanto, a presença de um sendrec é inaceitável para o processo de finalização do driver. Uma alternativa (ao lado daquela sugerida anteriormente) é o RS enviar mensagens (pedindo o kill do processo) sem que ele fique bloqueado, isto é, no Minix, o RS poderia usar a função NOTIFY ao invés do SEND. Ao se trabalhar com drivers no Minix, é possível se observar outras situações anômalas:

6 O Minix não abaixa a prioridade do driver: Isso ocorre quando não se sobe o serviço com o period ajustado. Isso faz com que o RS não monitore o driver, portanto o Minix não sabe que o driver está em loop, portanto não é abaixada a prioridade. Dependendo de onde se coloca o loop infinito, o Minix só trava na segunda vez que o driver é chamado. Isso ocorre por duas condições em conjunto: o period não for ajustado e o loop for posto após a mensagem de SUSPEND. Isso faz com que a primeira chamada do driver o coloca em loop imperceptível ao RS. Ao se fazer a segunda chamada, não há resposta do driver, pois este, ainda está no loop anterior, o FS fica travado e ocorre o mesmo da situação de travamento explicada durante este relatório. Portanto, podemos observar que há diversas maneiras de enganar o sistema operacional do Minix para que o tratamento de loops infinitos cause danos sérios ao sistema. Infelizmente ainda não existe a total confiabilidade do Minix como divulgado. IV. CONCLUSÃO. CONSIDERAÇÃO SOBRE O DESEMPENHO E ROBUSTEZ DO MINIX. Após a constatação de que diversos processos entravam em deadlock no Minix devido a um loop infinito em um driver no Minix3, contradizendo o artigo do Tanenbaum, a próxima pergunta é: um sistema operacional microkernel tende a ser mais robusto em relação ao monolítico mesmo com um desempenho inferior? O artigo [14] compara o microkernel a um navio que tem seu casco dividido em compartimentos, de forma que se um compartimento for danificado, os outros compartimentos mantém o navio flutuando; porém como observamos no deadlock apresentado, de nada adianta o microkernel continuar vivo se processos usuários necessários para responder às system calls morrerem. A resposta é que encontramos indícios de que o Minix3 não é mais robusto que o monolítico por ser microkernel, ou seja, por isolar um kernel funcionando e criar condições para que drivers sejam restartados. O motivo para isso está na complexidade em se remover drivers. Dado que a tabela de processos é distribuída, é necessário que diversas mensagens sejam trocadas com o simples objetivo de restartar os drivers; e esse fluxo de mensagens não é analisado de forma global. Portanto a simplicidade do código do Minix é somente aparente já que a complexidade com que as mensagens são trocadas não é de fato analisada. Porém notamos que, sistemas monolíticos também podem ser mais robustos. Uma forma de se criar uma versão aprimorada do Linux e mais robusta é uma que lidasse com deadlocks. O próprio livro do Tanenbaum [15] sugere técnicas para destravar um sistema que entrou em deadlock. Por exemplo: uma técnica é semelhante à que foi usada no Minix3 e consiste em pingar um processo para ver se ele responde; removendo-o caso ele não responda. Outra técnica consiste em montar um grafo de processos bloqueados esperando por recursos e observar se existe um ciclo fechado. No caso do Minix, o grafo pode modelar que processo espera mensagem de qual processo. Outra pergunta é: a queda no desempenho compensa o aumento na robustez? Mesmo que houvesse de fato uma versão mais robusta que lidasse com o loop infinito em drivers de forma mais genérica, ou ainda, uma versão que pudesse detectar e lidar com deadlocks, não acreditamos que a queda de desempenho compensa o aumento da robustez e o argumento é bem simples. Já existem diversas técnicas para se lidar com deadlocks em sistemas operacionais, porém nenhuma dessas técnicas que aumentam a robustez do sistema operacional são utilizadas em sistemas operacionais monolíticos. O sistema operacional mais próximo de tratar de deadlocks que conhecemos é um sistema operacional montado na Escola Politécnica da USP usado em automação ferroviária. Esse sistema pingava os módulos e casos houvesse problemas, restartava todo o sistema. Sistemas operacionais convencionais não tratam de deadlocks porque eles são eventos raros e a queda de desempenho não justifica o aumento da robustez. Então de forma semelhante, consideramos que um possível aumento da robustez decorrente do uso de sistemas microkernel não venha a justificar a queda de desempenho. Isso pode ser útil somente em alguns tipos de sistemas onde a robustez é extremamente importante; mas como observamos nesse artigo, mesmo assim é difícil garantir o aumento da robustez em um sistema microkernel. É interessante observar que dentre os sistemas microkernel encontrados na literatura como Minix, Mach e L4, o L4 (que provém do L3) surgiu com o objetivo de melhorar o desempenho com que as mensagens são trocadas [16]; que é justamente o motivo pelo qual o Minix perde muito em desempenho. O artigo [14] advoga o uso de drivers rodando rodando em modo usuário com o objetivo de aumentar a robustez, mesmo que isso acarrete a perda de desempenho. Encontramos na literatura artigos que apoiam essa decisão, independentemente do sistema ser monolítico ou microkernel. Embora o Minix3 não tenha funcionado como o esperado, acreditamos que, com cuidado, seja possível construir um Minix que de fato funcione como previsto em [14]; porém isso só é válido para o caso dos drivers, não sendo válido para o FS ou o PM. Os drivers não costumam armazenar um bom volume de informações, mas um restart em um FS já é algo bem diferente. O FS armazena a parte da tabela de processos que diz qual arquivo está alocada a qual processo. Parece-nos extremamente complexo restartar o FS levando o sistema para uma situação de normalidade. Um restart no PM também pode ter consequências muito sérias já que ele armazena a informação sobre o uso da memória por parte dos processos. Na literatura, [14] enfatiza o uso de drivers em modo usuário. O argumento é de que a taxa de erros nos drivers é de 3 a 7 vezes mais alta do que o normal. Além disso, 70% do código de um kernel monolítico consiste em drivers. A taxa de erros nos drivers é mais alta, no caso do Windows, porque muitos drivers são escritos pelos fabricantes do hardware e não por uma equipe acostumada a escrever drivers para o Windows XP onde 85% das panes ocorem[8]. O artigo [8] comenta diversos projetos envolvendo os drivers. NOOKS é um projeto para o Linux que encapsula os drivers de forma a

7 impedir que erros nos drivers se propagem pelo sistema. Existe um projeto para Linux que faz o driver rodar em modo usuário com pequena queda de desempenho, mas ganho em robustez. O artigo [3] propõe uma forma de se rodar drivers no Linux escritos em Java. Ele argumenta que a maioria das panes em um sistema operacional ocorre em drivers e que a linguagem java permite se escrever código de forma mais segura. Assim, diversos trabalhos apontam que drivers rodando em modo usuário são mais robustos. Isso faz sentido, porque retirar um processo com um problema (ex: um loop infinito em um driver) é mais simples de tratar em modo usuário. Observando e testando o Minix3 não podemos afirmar que drivers com código errado são genericamente removidos pelo Reincarnation Server; ou seja, não podemos afirmar que o Minix3 seja tão robusto como é afirmado em [14]. Porém, supondo que a probabilidade de ocorrer um problema em um driver antes de ele responder ao FS seja relativamente baixa, então o Minix3 é de fato mais robusto. O artigo [13] propõe um sistema microkernel e trata das primitivas por ele oferecidas de uma forma matemática. Acreditamos que uma modelagem formal de como os processos interagem entre si pode levar a sistemas mais robustos. O fato de ser microkernel por si só não leva a concluir que o sistema operacional seja mais robusto pois seria necessário garantir que processos vitais (ex: FS e PM), mesmo que não rodando em modo kernel, são robustos. O fato da tabela de processos estar distribuída obriga diversos processos a se comuniquem continuamente. Assim, questionamos diversas afirmações em [8] quanto ao aumento da robustez devido ao microkernel. Uma forma objetiva para advogar em favor de sistemas monolíticos ou microkernel é deixar a argumentação teórica e usar estatística. Para isso, bastaria ter uma especificação de system calls como o padrão POSIX, comparar a taxa de falhas e o desempenho entre todos os sistemas operacionais que implementam o padrão POSIX ao rodarem certos aplicativos. Porém essa medida é difícil, uma vez que os sistemas operacionais não medem "taxa de falhas". No futuro pretendemos criar um medidor de taxa de falhas que seja implementada nos sistemas operacionais Linux e Minix (ambos seguem o POSIX), rodar os mesmos aplicativos em ambas as plataformas e depois comparar essas medidas. Por enquanto, apresentamos apenas um indício de que sistemas operacionais microkernel não implementam system calls de forma muito mais robusta do que sistemas monolíticos. Em relação ao ensino de sistemas operacionais com o Minix, os alunos acreditam ser importante estar em contato com um sistema de código aberto que permite ser estudado. Caso não tivéssemos acesso ao Minix, seria muito difícil observar um sistema microkernel e o quão robusto ele é, apesar da queda de desempenho. Apreciamos o Minix como uma boa ferramenta didática, mas o Minix3 ainda deve ser aprimorado para que possa lidar com falhas genéricas em drivers. REFERÊNCIAS [1] G. Aguirre, M. Errecalde, R. Guerrero, C. Kavka, G. Leguizamon, M. Printista, and R. Gallard. Experiencing Minix as a didactical aid for operating systems courses. SIGOPS Oper. Syst. Rev., 25(3):32 39, [2] Charles L. Anderson and Minh Nguyen. A survey of contemporary instructional operating systems for use in undergraduate courses. J. Comput. Small Coll., 21(1): , [3] Shan Chen, Lingling Zhou, Rendong Ying, and Yi Ge. Safe device driver model based on kernel-mode jvm. In VTDC 07: Proceedings of the 3rd international workshop on Virtualization technology in distributed computing, pages 1 8, New York, NY, USA, ACM. [4] P. Daquino, W. Leao, and H. Omoto. Problemas em drivers no Minix3. Relatorio3.pdf, março [5] Wenliang Du and Ronghua Wang. Seed: A suite of instructional laboratories for computer security education. J. Educ. Resour. Comput., 8(1):1 24, [6] Stephen J. Hartley. Experience with Minix in an operating systems lab. SIGCSE Bull., 22(3):34 38, [7] J. H. Hays. An operating systems course using Minix. SIGCSE Bull., 21(4):11 12, [8] Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg, and Andrew S. Tanenbaum. Construction of a highly dependable operating system. In EDCC 06: Proceedings of the Sixth European Dependable Computing Conference, pages 3 12, Washington, DC, USA, IEEE Computer Society. [9] Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg, and Andrew S. Tanenbaum. Minix 3: a highly reliable, self-repairing operating system. SIGOPS Oper. Syst. Rev., 40(3):80 89, [10] James Howatt. Operating systems projects: Minix revisited. SIGCSE Bull., 34(4): , [11] R. A. Mark, P. Daquino, and R. Silva. Driver para o Minix. jkinoshi/2008/projs/r3-pedrodaquino- Relatorio3.pdf março [12] N. Sautchuk, P. M. Kayatt, and R. Ruppel. Tame infinite loops. março [13] Artem Starostin and Alexandra Tsyban. Correct microkernel primitives. Electron. Notes Theor. Comput. Sci., 217: , [14] Andrew S. Tanenbaum, Jorrit N. Herder, and Herbert Bos. Can we make operating systems reliable and secure? Computer, 39(5):44 51, [15] Andrew S. Tanenbaum and Albert S. Woodhull. Operating Systems Design and Implementation (3rd Edition) (Prentice Hall Software Series). Prentice Hall, January [16] Liedtke, Jochen. "Improving IPC by kernel design". 14th ACM Symposium on Operating System Principles. Asheville, NC, USA. pp , December 1993). Jorge Kinoshita é graduado em Engenharia Elétrica pela Universidade de São Paulo (USP), São Paulo, Brasil, em Obteve o título de mestre em Engenharia Elétrica pela Universidade de São Paulo em 1991 e de Doutor, em Engenharia Elétrica pela Universidade de São Paulo em Atualmente é professor da Universidade de São Paulo e suas pesquisas se concentram na área de sistemas operacionais e processamento de linguagem natural. Helio Tadashi Omoto é aluno do curso de Engenharia de Computação na Escola Politécnica da Universidade de São Paulo. Cursou também Engenharia de Computação no Politecnico di Milano, em Milão na Itália. Atualmente trabalha no Grupo Pão de Açucar como Trainee. Pedro d Aquino F. F. de Sá Barbuda recebeu o título de Engenheiro de Computação pela Escola Politécnica da Universidade de São Paulo (EPUSP) em Atualmente é aluno de Mestrado em Engenharia de Computação na mesma instituição. Suas áreas de interesse são sistemas operacionais, localização e mapeamento robótico e visão computacional. Wilson Leão Neto atualmente é aluno de Engenheira de Computação na Escola Politécnica da Universidade de São Paulo (EPUSP), previsão de formatura abril de Realizou um aproveitamento de créditos no Politecnico di Milano Itália ( ). Suas áreas de interesse são sistemas operacionais, pesquisa operacional, inteligência artificial e sistemas de decisão.

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com Sistemas Operacionais 2014 Introdução Alexandre Augusto Giron alexandre.a.giron@gmail.com Roteiro Sistemas Operacionais Histórico Estrutura de SO Principais Funções do SO Interrupções Chamadas de Sistema

Leia mais

Sistemas Operacionais I Parte III Estrutura dos SOs. Prof. Gregorio Perez gregorio@uninove.br 2007. Roteiro. Componentes do Sistema

Sistemas Operacionais I Parte III Estrutura dos SOs. Prof. Gregorio Perez gregorio@uninove.br 2007. Roteiro. Componentes do Sistema Sistemas Operacionais I Parte III Estrutura dos SOs Prof. Gregorio Perez gregorio@uninove.br 2007 Roteiro Serviços Estrutura dos Sistemas Operacionais Funções do Sistema Operacional Chamadas do Sistema

Leia mais

Introdução à Ciência da Computação

Introdução à Ciência da Computação Faculdade de Ciências e Tecnologia Departamento de Matemática e Computação Bacharelado em Ciência da Computação Introdução à Ciência da Computação Aula 05 Rogério Eduardo Garcia (rogerio@fct.unesp.br)

Leia mais

Sistemas Operacionais

Sistemas Operacionais UNIVERSIDADE BANDEIRANTE DE SÃO PAULO INSTITUTO POLITÉCNICO CURSO DE SISTEMAS DE INFORMAÇÃO Sistemas Operacionais Notas de Aulas: Tópicos 7 e 8 Estrutura do Sistema Operacional São Paulo 2009 1 Sumário

Leia mais

Sistemas Operacionais. Prof. Pedro Luís Antonelli Anhanguera Educacional

Sistemas Operacionais. Prof. Pedro Luís Antonelli Anhanguera Educacional Sistemas Operacionais Prof. Pedro Luís Antonelli Anhanguera Educacional INTRODUÇÃO Sistema Operacional (S.O.) Aplicativos Formado por um conjunto de rotinas que oferecem serviços aos usuários, às aplicações

Leia mais

Prof. Marcos Ribeiro Quinet de Andrade Universidade Federal Fluminense - UFF Pólo Universitário de Rio das Ostras - PURO

Prof. Marcos Ribeiro Quinet de Andrade Universidade Federal Fluminense - UFF Pólo Universitário de Rio das Ostras - PURO Conceitos básicos e serviços do Sistema Operacional Prof. Marcos Ribeiro Quinet de Andrade Universidade Federal Fluminense - UFF Pólo Universitário de Rio das Ostras - PURO Tipos de serviço do S.O. O S.O.

Leia mais

SISTEMAS OPERACIONAIS. Apostila 03 Estrutura do Sistema Operacional UNIBAN

SISTEMAS OPERACIONAIS. Apostila 03 Estrutura do Sistema Operacional UNIBAN SISTEMAS OPERACIONAIS Apostila 03 Estrutura do Sistema Operacional UNIBAN 1.0 O Sistema Operacional como uma Máquina Virtual A arquitetura (conjunto de instruções, organização de memória, E/S e estrutura

Leia mais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais Notas da Aula 15 - Fundamentos de Sistemas Operacionais 1. Software de Entrada e Saída: Visão Geral Uma das tarefas do Sistema Operacional é simplificar o acesso aos dispositivos de hardware pelos processos

Leia mais

SO - Conceitos Básicos. Introdução ao Computador 2010/01 Renan Manola

SO - Conceitos Básicos. Introdução ao Computador 2010/01 Renan Manola SO - Conceitos Básicos Introdução ao Computador 2010/01 Renan Manola Definição de SO É uma camada de software que opera entre o hardware e os programas aplicativos voltados ao usuário final. É uma estrutura

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Sistemas de Entrada/Saída Princípios de Hardware Sistema de Entrada/Saída Visão Geral Princípios de Hardware Dispositivos de E/S Estrutura Típica do Barramento de um PC Interrupções

Leia mais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais Arquitetura de Computadores Introdução aos Sistemas Operacionais O que é um Sistema Operacional? Programa que atua como um intermediário entre um usuário do computador ou um programa e o hardware. Os 4

Leia mais

Sistemas Operacionais. Prof. M.Sc. Sérgio Teixeira. Aula 05 Estrutura e arquitetura do SO Parte 2. Cursos de Computação

Sistemas Operacionais. Prof. M.Sc. Sérgio Teixeira. Aula 05 Estrutura e arquitetura do SO Parte 2. Cursos de Computação Cursos de Computação Sistemas Operacionais Prof. M.Sc. Sérgio Teixeira Aula 05 Estrutura e arquitetura do SO Parte 2 Referência: MACHADO, F.B. ; MAIA, L.P. Arquitetura de Sistemas Operacionais. 4.ed. LTC,

Leia mais

Figura 01 Kernel de um Sistema Operacional

Figura 01 Kernel de um Sistema Operacional 01 INTRODUÇÃO 1.5 ESTRUTURA DOS SISTEMAS OPERACIONAIS O Sistema Operacional é formado por um Conjunto de rotinas (denominado de núcleo do sistema ou kernel) que oferece serviços aos usuários e suas aplicações

Leia mais

SISTEMAS OPERACIONAIS

SISTEMAS OPERACIONAIS SISTEMAS OPERACIONAIS Tópico 4 Estrutura do Sistema Operacional Prof. Rafael Gross prof.rafaelgross@fatec.sp.gov.br FUNÇÕES DO NUCLEO As principais funções do núcleo encontradas na maioria dos sistemas

Leia mais

Conceitos Básicos sobre Sistemas Operacionais

Conceitos Básicos sobre Sistemas Operacionais Conceitos Básicos sobre Sistemas Operacionais Ivanovitch Medeiros Dantas da Silva Universidade Federal do Rio Grande do Norte Departamento de Engenharia de Computação e Automação DCA0800 - Algoritmos e

Leia mais

4 Estrutura do Sistema Operacional. 4.1 - Kernel

4 Estrutura do Sistema Operacional. 4.1 - Kernel 1 4 Estrutura do Sistema Operacional 4.1 - Kernel O kernel é o núcleo do sistema operacional, sendo responsável direto por controlar tudo ao seu redor. Desde os dispositivos usuais, como unidades de disco,

Leia mais

Sistemas Operacionais

Sistemas Operacionais Universidade Estadual de Mato Grosso do Sul UEMS Curso de Licenciatura em Computação Sistemas Operacionais Prof. José Gonçalves Dias Neto profneto_ti@hotmail.com Sistemas Operacionais Carga horária total:

Leia mais

TempOS: faça seu próprio sistema operacional à mão, e do zero!

TempOS: faça seu próprio sistema operacional à mão, e do zero! TempOS: faça seu próprio sistema operacional à mão, e do zero! Renê de Souza Pinto Instituto de Ciências Matemáticas e de Computação - ICMC Universidade de São Paulo - USP - São Carlos Abril / 2013 Renê

Leia mais

Processos e Threads (partes I e II)

Processos e Threads (partes I e II) Processos e Threads (partes I e II) 1) O que é um processo? É qualquer aplicação executada no processador. Exe: Bloco de notas, ler um dado de um disco, mostrar um texto na tela. Um processo é um programa

Leia mais

Sistemas Operacionais. Conceitos de um Sistema Operacional

Sistemas Operacionais. Conceitos de um Sistema Operacional Sistemas Operacionais Conceitos de um Sistema Operacional Modo usuário e Modo Kernel Como já vimos são ambientes de execução diferentes no processador Há um conjunto de funções privilegiadas acessadas

Leia mais

Sistemas Operacionais. Prof. M.Sc. Sérgio Teixeira. Aula 05 Estrutura e arquitetura do SO Parte 1. Cursos de Computação

Sistemas Operacionais. Prof. M.Sc. Sérgio Teixeira. Aula 05 Estrutura e arquitetura do SO Parte 1. Cursos de Computação Cursos de Computação Sistemas Operacionais Prof. M.Sc. Sérgio Teixeira Aula 05 Estrutura e arquitetura do SO Parte 1 Referência: MACHADO, F.B. ; MAIA, L.P. Arquitetura de Sistemas Operacionais. 4.ed. LTC,

Leia mais

Programação de Sistemas

Programação de Sistemas Programação de Sistemas Arquitectura dos Sistemas Operativos Programação de Sistemas Arquitectura : 1/25 Introdução (1) Um sistema operativo de uso geral é formado por diversas componentes: Gestor de processos

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Sistemas de Entrada/Saída Princípios de Software Sistema de Entrada/Saída Princípios de Software Tratadores (Manipuladores) de Interrupções Acionadores de Dispositivos (Device Drivers)

Leia mais

Introdução. O que vimos. Infraestrutura de Software. (cont.) História dos Sistemas Operacionais. O que vimos 12/03/2012. Primeira geração: 1945-1955

Introdução. O que vimos. Infraestrutura de Software. (cont.) História dos Sistemas Operacionais. O que vimos 12/03/2012. Primeira geração: 1945-1955 O que vimos Infraestrutura de Software Introdução (cont.) Complexidade do computador moderno, do ponto de vista do hardware Necessidade de abstrações software Sistema computacional em camadas SO como uma

Leia mais

Pós-Graduação, Maio de 2006 Introdução aos Sistemas Operacionais. Prof. Dr. Ruy de Oliveira CEFET-MT

Pós-Graduação, Maio de 2006 Introdução aos Sistemas Operacionais. Prof. Dr. Ruy de Oliveira CEFET-MT Pós-Graduação, Maio de 2006 Introdução aos Sistemas Operacionais Prof. Dr. Ruy de Oliveira CEFET-MT O que é um Sistema Operacional? Um software que abstrai as complexidades do hardware de um usuário/programador

Leia mais

Sistemas Operacionais Aula 03: Estruturas dos SOs. Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com

Sistemas Operacionais Aula 03: Estruturas dos SOs. Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com Sistemas Operacionais Aula 03: Estruturas dos SOs Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com OBJETIVOS Descrever os serviços que um sistema operacional oferece aos usuários e outros sistemas

Leia mais

Usuários. Aplicativos e programas dos usuários. Kernel gerenciamento de processos, memória, sistema de arquivos, I/O, etc.

Usuários. Aplicativos e programas dos usuários. Kernel gerenciamento de processos, memória, sistema de arquivos, I/O, etc. 1 1.0 Kernel O kernel (núcleo) representa o coração do Sistema Operacional. Atribuições do kernel: - gerenciamento dos arquivos em disco; - inicializar programas e executá-los; - alocar e gerenciar memória

Leia mais

SISTEMAS OPERACIONAIS 2007

SISTEMAS OPERACIONAIS 2007 SISTEMAS OPERACIONAIS 2007 VISÃO GERAL Sumário Conceito Máquina de Níveis Conceituação de SO Componentes do SO Visões do SO Conceito de Sistemas O que se espera de um sistema de computação? Execução de

Leia mais

Sistemas Operativos I

Sistemas Operativos I Componentes de um Sistema Operativo Maria João Viamonte / Luis Lino Ferreira Fevereiro de 2006 Sistema Operativo Um Sistema Operativo pode ser visto como um programa de grande complexidade, responsável

Leia mais

Programação Concorrente Processos e Threads

Programação Concorrente Processos e Threads Programação Concorrente Processos e Threads Prof. Eduardo Alchieri Processos O conceito mais central em qualquer sistema operacional é o processo Uma abstração de um programa em execução Um programa por

Leia mais

1º Estudo Dirigido. Capítulo 1 Introdução aos Sistemas Operacionais

1º Estudo Dirigido. Capítulo 1 Introdução aos Sistemas Operacionais 1º Estudo Dirigido Capítulo 1 Introdução aos Sistemas Operacionais 1. Defina um sistema operacional de uma forma conceitual correta, através de suas palavras. R: Sistemas Operacionais são programas de

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Aula 6 Estrutura de Sistemas Operacionais Prof.: Edilberto M. Silva http://www.edilms.eti.br Baseado no material disponibilizado por: SO - Prof. Edilberto Silva Prof. José Juan Espantoso

Leia mais

SO Sistemas Operacionais

SO Sistemas Operacionais GOVERNO DO ESTADO DO RIO DE JANEIRO FUNDAÇÃO DE APOIO A ESCOLA TÉCNICA ESCOLA TÉCNICA ESTADUAL REPÚBLICA SO Sistemas Operacionais Curso de Informática ETE REPÚBLICA - Rua Clarimundo de Melo, 847, Quintino

Leia mais

Infra-Estrutura de Software. Introdução. (cont.)

Infra-Estrutura de Software. Introdução. (cont.) Infra-Estrutura de Software Introdução (cont.) O que vimos Complexidade do computador moderno, do ponto de vista do hardware Necessidade de abstrações software Sistema computacional em camadas SO como

Leia mais

Sistemas Operacionais Arquitetura e organização de sistemas operacionais: Uma visão estrutural hardware & software. Prof. MSc.

Sistemas Operacionais Arquitetura e organização de sistemas operacionais: Uma visão estrutural hardware & software. Prof. MSc. Sistemas Operacionais Arquitetura e organização de sistemas operacionais: Uma visão estrutural hardware & software Prof. MSc. Hugo Souza Continuando nossas aulas relativas ao Módulo 1, veremos a seguir

Leia mais

Chamadas de Sistema e Processo

Chamadas de Sistema e Processo Andrique Amorim www.andrix.com.br professor@andrix.com.br Chamadas de Sistema e Processo Estrutura do Computador Sistemas Operacionais Estrutura do Computador Sistemas Operacionais Modos de Acesso ao S.O.

Leia mais

Sistemas Operacionais - Prof. Fabricio Alessi Steinmacher - email:fsteinmacher@gmail.com OBJETIVOS OPERACIONAIS. fsteinmacher@gmail.

Sistemas Operacionais - Prof. Fabricio Alessi Steinmacher - email:fsteinmacher@gmail.com OBJETIVOS OPERACIONAIS. fsteinmacher@gmail. SISTEMAS Introdução a Sistemas Operacionais Prof. Fabricio Alessi Steinmacher - email: OBJETIVOS Identificar as funções e os componentes de um Sistema Operacional; Diferenciar os tipos de Sistemas Operacionais

Leia mais

Sistemas Operacionais Cap 3 Estruturas de Sistemas Operacionais. Podemos analisar um sistema operacional sob diversos aspectos:

Sistemas Operacionais Cap 3 Estruturas de Sistemas Operacionais. Podemos analisar um sistema operacional sob diversos aspectos: Estruturas de Sistemas Operacionais Podemos analisar um sistema operacional sob diversos aspectos: Os serviços que o sistema operacional oferece. A interface que o sistema operacional torna disponível

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Conceitos Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno Sumário Introdução Arquitetura de Sistema Operacional Chamadas de sistema. Processos Basicamente, um

Leia mais

6 - Gerência de Dispositivos

6 - Gerência de Dispositivos 1 6 - Gerência de Dispositivos 6.1 Introdução A gerência de dispositivos de entrada/saída é uma das principais e mais complexas funções do sistema operacional. Sua implementação é estruturada através de

Leia mais

Estrutura de S.O. Roteiro. BC1518 - Sistemas Operacionais. Prof. Marcelo Z. do Nascimento. Aula 02 2 Quadrimestre. de 2010

Estrutura de S.O. Roteiro. BC1518 - Sistemas Operacionais. Prof. Marcelo Z. do Nascimento. Aula 02 2 Quadrimestre. de 2010 BC1518 - Sistemas Operacionais Estrutura de S.O. Aula 02 2 Quadrimestre de 2010 Prof. Marcelo Z. do Nascimento Email: marcelo.nascimento@ufabc.edu.br Roteiro Serviço do sistema operacional Interface Chamadas

Leia mais

SW DE E/S INDEPENDENTE DE DISPOSITIVO

SW DE E/S INDEPENDENTE DE DISPOSITIVO SOFTWARE AO NÍVEL DO USUÁRIO SOFTWARE INDEPENDENTE DE DISPOSITIVOS ACIONADORES DE DISPOSITIVOS (DRIVERS) TRATAMENTO DE INTERRUPÇÕES HARDWARE FUNÇÕES: INTERFACE UNIFORME PARA OS DRIVERS USO DE BUFFERS INFORMAÇÃO

Leia mais

Sistemas Operacionais Introdução

Sistemas Operacionais Introdução Sistemas Operacionais Introdução Adriano J. Holanda http://holanda.xyz 3/8/2015 Sistemas de computação teclado mouse impressora disco rígido monitor processador controladora de disco controladora USB placa

Leia mais

Chamadas de Sistema e Processo

Chamadas de Sistema e Processo Andrique Amorim www.andrix.com.br professor@andrix.com.br Chamadas de Sistema e Processo Estrutura do Computador Sistemas Operacionais Estrutura do Computador Sistemas Operacionais Modos de Acesso ao S.O.

Leia mais

SISTEMAS OPERACIONAIS ABERTOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

SISTEMAS OPERACIONAIS ABERTOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 2-1. PRINCÍPIOS DE SOFTWARE DE ENTRADA E SAÍDA (E/S) As metas gerais do software de entrada e saída é organizar o software como uma série de camadas, com as mais baixas preocupadas em esconder as

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Aula 07 Arquitetura de Sistemas Operacionais Prof. Maxwell Anderson www.maxwellanderson.com.br Introdução Conceitos já vistos em aulas anteriores: Definição de Sistemas Operacionais

Leia mais

Resumo até aqui. Gerenciamento Proteção Compartilhamento. Infra-estrutura de Software

Resumo até aqui. Gerenciamento Proteção Compartilhamento. Infra-estrutura de Software Resumo até aqui Complexidade do computador moderno, do ponto de vista do hardware Necessidade de abstrações software Sistema computacional em camadas SO como uma máquina estendida abstrações SO como um

Leia mais

Arquitetura de Sistemas Operacionais Machado/Maia. Arquitetura de Sistemas

Arquitetura de Sistemas Operacionais Machado/Maia. Arquitetura de Sistemas Arquitetura de Sistemas Operacionais Capítulo 4 Estrutura do Sistema Operacional Cap. 4 Estrutura do Sistema 1 Sistemas Operacionais Pitágoras Fadom Divinópolis Material Utilizado na disciplina Sistemas

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Gerência de processos Controle e descrição de processos Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno Sumário Representação e controle de processos pelo SO Estrutura

Leia mais

IFPE. Disciplina: Sistemas Operacionais. Prof. Anderson Luiz Moreira

IFPE. Disciplina: Sistemas Operacionais. Prof. Anderson Luiz Moreira IFPE Disciplina: Sistemas Operacionais Prof. Anderson Luiz Moreira SERVIÇOS OFERECIDOS PELOS SOS 1 Introdução O SO é formado por um conjunto de rotinas (procedimentos) que oferecem serviços aos usuários

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais SINCRONIZAÇÃO E COMUNICAÇÃO ENTRE PROCESSOS MACHADO/MAIA: CAPÍTULO 07, PÁGINA 101 Prof. Pedro Luís Antonelli Anhanguera Educacional sistemas multiprogramáveis Os sistemas multiprogramáveis

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

SISTEMAS OPERACIONAIS

SISTEMAS OPERACIONAIS SISTEMAS OPERACIONAIS Arquitetura Sistemas Operacionais Andreza Leite andreza.leite@univasf.edu.br Plano de Aula Sistemas monolíticos Sistemas em camadas Sistemas micro-núcleo Modelo Cliente-Servidor Máquinas

Leia mais

VI - Introdução aos Sistemas Operacionais

VI - Introdução aos Sistemas Operacionais VI - Introdução aos Sistemas Operacionais Consiste de um ou um conjunto de programas que compõem o software básico do computador e cuja finalidade é a de executar os programas aplicativos e de servir de

Leia mais

E/S PROGRAMADA E/S PROGRAMADA E/S USANDO INTERRUPÇÃO

E/S PROGRAMADA E/S PROGRAMADA E/S USANDO INTERRUPÇÃO E/S PROGRAMADA QUANDO A CPU FAZ TODO O TRABALHO RELACIONADO A UMA OPERAÇÃO DE E/S, NO CASO DO PROCESSO QUERER IMPRIMIR (NA IMPRESSORA) ABCDEFGH : ESTES CARACTERES SÃO COLOCADOS EM UMA ÁREA DE MEMÓRIA DO

Leia mais

11/3/2009. Software. Sistemas de Informação. Software. Software. A Construção de um programa de computador. A Construção de um programa de computador

11/3/2009. Software. Sistemas de Informação. Software. Software. A Construção de um programa de computador. A Construção de um programa de computador Sistemas de Informação Prof. Anderson D. Moura Um programa de computador é composto por uma seqüência de instruções, que é interpretada e executada por um processador ou por uma máquina virtual. Em um

Leia mais

Visão Geral de Sistemas Operacionais

Visão Geral de Sistemas Operacionais Visão Geral de Sistemas Operacionais Sumário Um sistema operacional é um intermediário entre usuários e o hardware do computador. Desta forma, o usuário pode executar programas de forma conveniente e eficiente.

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Prof. Dr. Márcio Andrey Teixeira Estrutura de sistemas operacionais Estruturas de sistemas operacionais A estrutura e o funcionamento de um SO são tópicos de difícil compreensão.

Leia mais

Introdução à Programação de Computadores

Introdução à Programação de Computadores 1. Objetivos Introdução à Programação de Computadores Nesta seção, vamos discutir os componentes básicos de um computador, tanto em relação a hardware como a software. Também veremos uma pequena introdução

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Prof. Jó Ueyama Apresentação baseada nos slides da Profa. Dra. Kalinka Castelo Branco, do Prof. Dr. Antônio Carlos Sementille, da Profa. Dra. Luciana A. F. Martimiano e nas transparências

Leia mais

Sistema Operacional. Processo e Threads. Prof. Dr. Márcio Andrey Teixeira Sistemas Operacionais

Sistema Operacional. Processo e Threads. Prof. Dr. Márcio Andrey Teixeira Sistemas Operacionais Sistema Operacional Processo e Threads Introdução a Processos Todos os computadores modernos são capazes de fazer várias coisas ao mesmo tempo. Enquanto executa um programa do usuário, um computador pode

Leia mais

Fundamentos de Sistemas Computacionais Introdução

Fundamentos de Sistemas Computacionais Introdução Fundamentos de Sistemas Computacionais Introdução Prof. Eduardo Alchieri Sistema Computacional Hardware Software Usuários Um ou mais processadores, memória, discos, impressoras, teclado, mouse, monitor,

Leia mais

ESTRUTURA DE UM SISTEMA OPERACIONAL

ESTRUTURA DE UM SISTEMA OPERACIONAL ESTRUTURA DE UM SISTEMA OPERACIONAL Prof. Me. Hélio Esperidião VISÃO DO USUÁRIO DE UM SO Imagem que o usuário tem do sistema Interface para acesso aos recursos. EXECUTAR PROGRAMAS Todo sistema operacional

Leia mais

Arquitetura dos Sistemas Operacionais

Arquitetura dos Sistemas Operacionais Arquitetura dos Sistemas Operacionais Arquitetura de um Sistema Operacional Basicamente dividido em shell é a interface entre o usuário e o sistema operacional é um interpretador de comandos possui embutido

Leia mais

Estrutura, Processos e Threads

Estrutura, Processos e Threads Estrutura, Processos e Threads Prof. Edwar Saliba Júnior Março de 2007 1 Sistema computacional A p l i c a t i v o s U t i l i t á r i o s N ú c l e o d o S i s t e m a O p e r a c i o n a l H a r d w

Leia mais

Ciclo de Vida de um Processo

Ciclo de Vida de um Processo Nas aulas anteriores Ciclo de Vida de um Processo Marcelo Johann Conceito de Processo Mecanismo de Programação em C/UNIX Continuando Interrupções TRAP Chaveamento de Contexto Chamadas de Sistema INF01142

Leia mais

Sistemas Operacionais. (Capítulo 3) INTRODUÇÃO À ENGENHARIA DA COMPUTAÇÃO. Professor: Rosalvo Ferreira de Oliveira Neto

Sistemas Operacionais. (Capítulo 3) INTRODUÇÃO À ENGENHARIA DA COMPUTAÇÃO. Professor: Rosalvo Ferreira de Oliveira Neto Sistemas Operacionais (Capítulo 3) INTRODUÇÃO À ENGENHARIA DA COMPUTAÇÃO Professor: Rosalvo Ferreira de Oliveira Neto Estrutura 1. Definições 2. Classificações 3. CPU 4. Memória 5. Utilitários O que se

Leia mais

ENTRADA E SAÍDA (I/O)

ENTRADA E SAÍDA (I/O) MICROPROCESSADORES II (EMA864315) ENTRADA E SAÍDA (I/O) 1 O SEMESTRE / 2015 Alexandro Baldassin MATERIAL DIDÁTICO Patterson & Hennessy (4a edição) Capítulo 6 (Tópicos I/O) 6.1 Introduction 6.5 Connecting

Leia mais

Informática I. Aula 19. http://www.ic.uff.br/~bianca/informatica1/ Aula 19-20/11/06 1

Informática I. Aula 19. http://www.ic.uff.br/~bianca/informatica1/ Aula 19-20/11/06 1 Informática I Aula 19 http://www.ic.uff.br/~bianca/informatica1/ Aula 19-20/11/06 1 Ementa Histórico dos Computadores Noções de Hardware e Software Microprocessadores Sistemas Numéricos e Representação

Leia mais

Introdução a Computação

Introdução a Computação Sistemas Operacionais: Software Oculto Introdução a Computação Sistemas Operacionais Serve como um intermediário entre o hardware e os softwares aplicativos. Sistema Operacional Software de sistemas Kernel

Leia mais

Programação de Computadores

Programação de Computadores Programação de Computadores Aula 04: Sistema Operacional Material Didático do Livro: Introdução à Informática Capron,, H. L. e Johnson, J. A Pearson Education Sistemas Operacionais: Software Oculto Serve

Leia mais

SISTEMAS OPERACIONAIS ABERTOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

SISTEMAS OPERACIONAIS ABERTOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Módulo 4 - ENTRADAS E SAIDAS Uma das principais funções dos sistemas operacionais é controlar os dispositivos de entrada e saída (E/S ou I/O). O Sistema Operacional deve ser capaz de enviar comandos

Leia mais

Estudo de Caso 2: Windows Vista

Estudo de Caso 2: Windows Vista Faculdades Integradas de Mineiros Curso de Sistemas de Informação Sistemas Operacionais II Estudo de Caso 2: Windows Vista Grupo 4 Helder / Wagner / Frantyeis Junho/2010 O Windows usa uma estratégia Just-In-Time

Leia mais

PLANO DE ENSINO DA DISCIPLINA

PLANO DE ENSINO DA DISCIPLINA PONTIFÍCIA UNIVERSIDADE CATÓLICA DE CAMPINAS PLANO DE ENSINO DA DISCIPLINA CENTRO DE CIÊNCIAS EXATAS, AMBIENTAIS E DE TECNOLOGIAS CURSO: ENGENHARIA DE COMPUTAÇÃO DISCIPLINA: SISTEMAS OPERACIONAIS B CÓDIGO:

Leia mais

Módulo 4: Processos. Conceito de Processo. Escalonamento de processos Operações sobre processos Processos cooperantes Comunicação entre processos

Módulo 4: Processos. Conceito de Processo. Escalonamento de processos Operações sobre processos Processos cooperantes Comunicação entre processos Módulo 4: Processos Conceito de Processo Escalonamento de processos Operações sobre processos Processos cooperantes Comunicação entre processos 4.1 Conceito de Processo Um Sistema Operacional executa uma

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Aula 01 - Introdução Prof. Maxwell Anderson www.maxwellanderson.com.br Capítulo 1: Introdução O que é um sistema operacional? Componentes de um sistema operacional O que faz parte

Leia mais

Sistemas Operacionais. Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com

Sistemas Operacionais. Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com Sistemas Operacionais Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com Estruturas de Sistemas de Computação O sistema operacional precisa garantir a operação correta do sistema de computação. Operação

Leia mais

Trabalho 3. MC404, 1 o semestre de 2012, turmas A e B 19 de junho de 2012

Trabalho 3. MC404, 1 o semestre de 2012, turmas A e B 19 de junho de 2012 Trabalho 3 MC404, 1 o semestre de 2012, turmas A e B 19 de junho de 2012 O trabalho 3 é dividido em duas partes: código de sistema e código de usuário. Estas partes estão descritas nas seções abaixo. Você

Leia mais

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro Introdução Sistemas Operacionais 1 Sistema Operacional: Um conjunto de programas, executado pelo computador como os outros programas. Função: Controlar o funcionamento do computador, disponibilizando seus

Leia mais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais Notas da Aula 4 - Fundamentos de Sistemas Operacionais 1. Threads Threads são linhas de execução dentro de um processo. Quando um processo é criado, ele tem uma única linha de execução, ou thread. Esta

Leia mais

Sistemas Operacionais Introdução

Sistemas Operacionais Introdução Sistemas Operacionais Introdução Adriano J. Holanda http://adrianoholanda.org/edu/ 5 de agosto de 2013 Introdução Sobre o curso Introdução Complexidade dos SOs Informações sobre a disciplina Serviços Arquitetura

Leia mais

3 Noções de Sistemas Operacionais

3 Noções de Sistemas Operacionais 3 Noções de Sistemas Operacionais Para que o hardware ou parte física de um computador possa funcionar faz-se necessário um conjunto de regras e ordens que coordenem todos os processos realizados. Tal

Leia mais

Capítulo 2 Processos e Threads Prof. Fernando Freitas

Capítulo 2 Processos e Threads Prof. Fernando Freitas slide 1 Capítulo 2 Processos e Threads Prof. Fernando Freitas Material adaptado de: TANENBAUM, Andrew S. Sistemas Operacionais Modernos. 3ª edição. Disponível em: http://www.prenhall.com/tanenbaum_br slide

Leia mais

2 SYSCALLs: O que são

2 SYSCALLs: O que são Trabalho de Software Básico - Turma 2010-1 Nome: Francisco Panis Kaseker GRR20071909 Título: Explicação e implementação de uma SYSCALL Data: 30/06/2010 1 Introdução Basicamente uma SYSCALL é uma chamada

Leia mais

Desenvolvimento para Sistemas Embarcados (CEA 513) Conceitos Gerais

Desenvolvimento para Sistemas Embarcados (CEA 513) Conceitos Gerais Universidade Federal de Ouro Preto Departamento de Computação e Sistemas - DECSI Desenvolvimento para Sistemas Embarcados (CEA 513) Conceitos Gerais Vicente Amorim vicente.amorim.ufop@gmail.com Sumário

Leia mais

Automatização de Aplicativos Windows usando o AutoHotKey

Automatização de Aplicativos Windows usando o AutoHotKey Automatização de Aplicativos Windows usando o AutoHotKey Muitos processos de negócio dependem de aplicativos de terceiros que assumem a presença de um operador humano para executar determinadas rotinas.

Leia mais

Estruturas do Sistema de Computação

Estruturas do Sistema de Computação Estruturas do Sistema de Computação Prof. Dr. José Luís Zem Prof. Dr. Renato Kraide Soffner Prof. Ms. Rossano Pablo Pinto Faculdade de Tecnologia de Americana Centro Paula Souza Estruturas do Sistema de

Leia mais

P5 P3. interrupçãocorrespondente. Sistemas Operacionais 2008/1 Profa. Patricia D. CostaLPRM/DI/UFES 3 Sistemas Operacionais 2008/1

P5 P3. interrupçãocorrespondente. Sistemas Operacionais 2008/1 Profa. Patricia D. CostaLPRM/DI/UFES 3 Sistemas Operacionais 2008/1 Conceitos Processos Básicos (Aula 4) Profa. É Provoca Constitui Mecanismo Patricia informa evento controle, a multiprogramação. Ex: rotina um a base de Interrupção de um (1) sistema de D. CostaLPRM/DI/UFES

Leia mais

Notas da Aula 6 - Fundamentos de Sistemas Operacionais

Notas da Aula 6 - Fundamentos de Sistemas Operacionais 1. Monitores Notas da Aula 6 - Fundamentos de Sistemas Operacionais Embora os semáforos sejam uma boa solução para o problema da exclusão mútua, sua utilização não é trivial. O programador é obrigado a

Leia mais

Sistemas Operacionais. Alexandre Meslin meslin@inf.puc-rio.br

Sistemas Operacionais. Alexandre Meslin meslin@inf.puc-rio.br Sistemas Operacionais Alexandre Meslin meslin@inf.puc-rio.br Ementa Apresentação do curso Cap1 - Visão Geral Cap2 - Conceitos de Hardware e Software Cap3 - Concorrência Cap4 - Estrutura do Sistema Operacional

Leia mais

Sistemas Operacionais. Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com

Sistemas Operacionais. Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com Sistemas Operacionais Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com Estruturas de Sistemas Operacionais Um sistema operacional fornece o ambiente no qual os programas são executados. Internamente,

Leia mais

Sistemas Operacionais Entrada / Saída. Carlos Ferraz (cagf@cin.ufpe.br) Jorge Cavalcanti Fonsêca (jcbf@cin.ufpe.br)

Sistemas Operacionais Entrada / Saída. Carlos Ferraz (cagf@cin.ufpe.br) Jorge Cavalcanti Fonsêca (jcbf@cin.ufpe.br) Sistemas Operacionais Entrada / Saída Carlos Ferraz (cagf@cin.ufpe.br) Jorge Cavalcanti Fonsêca (jcbf@cin.ufpe.br) Tópicos Princípios do hardware de E/S Princípios do software de E/S Camadas do software

Leia mais

Princípios de TI - Computadores. Sistema Operacional. CECOMP Colegiado de Engenharia da Computação. Prof. Fábio Nelson. Slide 1

Princípios de TI - Computadores. Sistema Operacional. CECOMP Colegiado de Engenharia da Computação. Prof. Fábio Nelson. Slide 1 Sistema Operacional Slide 1 Sistema Operacional Um conjunto de programas que se situa entre os softwares aplicativos e o hardware: Gerencia os recursos do computador (CPU, dispositivos periféricos). Estabelece

Leia mais

Entrada e Saída. Interface entre periféricos, processador e memória. Fonte: Minho - Portugal 1

Entrada e Saída. Interface entre periféricos, processador e memória. Fonte: Minho - Portugal 1 Entrada e Saída Interface entre periféricos, processador e memória Fonte: Minho - Portugal 1 Ligação Processador/Memória - Periférico Processador Memória Controlo Dados Controlador Fonte: Minho - Portugal

Leia mais

Sistemas de Arquivos Distribuídos. Universidade Federal do ABC Prof. Dr. Francisco Isidro Massetto

Sistemas de Arquivos Distribuídos. Universidade Federal do ABC Prof. Dr. Francisco Isidro Massetto Sistemas de Arquivos Distribuídos Universidade Federal do ABC Prof. Dr. Francisco Isidro Massetto Conceitos Dois tipos Stateless Statefull Statefull Mantém informações de estado Nome do arquivo Ponteiro

Leia mais

Windows NT 4.0. Centro de Computação

Windows NT 4.0. Centro de Computação Windows NT 4.0 Centro de Computação Tópicos Introdução Instalação Configuração Organização da rede Administração Usuários Servidores Domínios Segurança Tópicos È O sistema operacional Windows NT È Características:

Leia mais

Sistemas Operacionais. Estruturas de SO. Edeyson Andrade Gomes. www.edeyson.com.br

Sistemas Operacionais. Estruturas de SO. Edeyson Andrade Gomes. www.edeyson.com.br Sistemas Operacionais Estruturas de SO Edeyson Andrade Gomes www.edeyson.com.br Roteiro da Aula Estrutura do SO Chamadas ao Sistema Sistemas Monolíticos Sistemas em Camadas Sistemas Cliente-Servidor 2

Leia mais

Interrupções. As interrupções são casos especiais de chamadas de procedimentos.

Interrupções. As interrupções são casos especiais de chamadas de procedimentos. Interrupções Uma interrupção é equivalente a uma chamada de procedimento. A chamada é equivalente a um CALL gerado pela execução de uma instrução. As interrupções são casos especiais de chamadas de procedimentos.

Leia mais

Sistemas Operacionais - Introdução. Sistemas Operacionais - Funções. FACENS - Faculdade de Engenharia de Sorocaba

Sistemas Operacionais - Introdução. Sistemas Operacionais - Funções. FACENS - Faculdade de Engenharia de Sorocaba Sistemas Operacionais - Introdução Aplicações Compiladores Editores Interpretadores de comando Sistema Operacional Linguagem de Máquina Microarquitetura Dispositivos Físicos Sistemas Operacionais - Funções

Leia mais

Partição Partição primária: Partição estendida: Discos básicos e dinâmicos

Partição Partição primária: Partição estendida: Discos básicos e dinâmicos Partição Parte de um disco físico que funciona como se fosse um disco fisicamente separado. Depois de criar uma partição, você deve formatá-la e atribuir-lhe uma letra de unidade antes de armazenar dados

Leia mais