Principios do Software - Entrada e Saída

Prévia do material em texto

Sistemas Operacionais 
Princípios do software de E/S 
Prof. Sílvio Fernandes 
UNIVERSIDADE FEDERAL RURAL DO SEMI-ÁRIDO 
DEPARTAMENTO DE CIÊNCIAS EXATAS E NATURAIS 
CURSO DE CIÊNCIA DA COMPUTAÇÃO 
Introdução 
 O conceito primordial no projeto do SW de E/S 
é conhecido como independência de 
dispositivo, pela qual programas são aptos 
acessar qualquer dispositivo de E/S de uma 
maneira, seja ele um disquete, disco rígido, ou 
CD-ROM. 
 O conceito de nomeação uniforme, diz que o 
nome de cada arquivo ou dispositivo deveria 
ser uma simples cadeia de caracteres ou valor 
inteiro, totalmente independente do dispositivo 
2 
Introdução 
 Em relação ao tratamento de erros há o 
conceito de que eles devem ser tratados o 
mais “próximo” do hardware possível 
 Se um controlador descobre um erro ele deve 
tratá-lo, caso não tenha condições para isso o 
erro deve ser informado ao driver do dispositivo 
que também tenta tratá-lo 
3 
Introdução 
 Em último caso o processo do usuário é 
informado que o houve um erro que não pode 
ser tratado 
4 
Introdução 
 Em relação a transferência de dados ela pode 
ser síncrona (bloqueante), que é a forma mais 
utilizada nas camadas de software de alto 
nível, por facilitar a programação 
 Ou assíncrona (orientada a interrupção), forma 
utilizada na E/S física 
 Outra questão é a utilização de buffer para 
armazenamento temporário 
 Muitas vezes os dados não podem ser armazenados 
nos seu destino final 
5 
Introdução 
 Outro conceito é o de dispositivo 
compartilhado versus dedicado 
 Alguns dispositivos (como discos) podem ser usados 
por muitos usuários ao mesmo tempo 
 Outros dispositivos (como fitas) devem ser dedicados 
a um único usuário até que finalize suas operações 
 Há 3 maneiras de realizar E/S 
 E/S programada 
 E/S orientada a interrupção 
 E/S que usa DMA 
6 
Camadas do Software de E/S 
 O software de E/S é normalmente dividido em 
quatro camadas, cada qual com funções e 
interfaces bem definidas para as camadas 
adjacente 
7 
Tratadores de interrupção 
 Por um lado E/S programada é eventualmente 
útil, por outro, para a maioria das E/S, as 
interrupções são um fato desagradável e não 
podem ser evitadas 
 A menor parte do SO é que deve saber da 
existência das interrupções 
 A melhor maneira de escondê-las é bloquear o 
driver que iniciou uma operação de E/S até 
que ela se complete e uma interrupção ocorra 
 O driver pode bloquear a si próprio 
8 
Tratadores de interrupção 
 Quando ocorre uma interrupção, a rotina de 
tratamento faz o necessário para tratar a 
interrupção e depois pode desbloquear o 
driver de dispositivo que a causou 
 Esse tratamento pode ser simples como a 
realização de um “up” sobre um semáforo ou 
muito mais complicada 
 Em todos os casos, o efeito resultante será que 
o driver previamente bloqueado esteja 
novamente apto a executar 
9 
Tratadores de interrupção 
1. Salva quaisquer registradores que ainda não 
foram salvos pelo hardware de interrupção 
2. Estabelece um contexto para a rotina de 
tratamento de interrupção 
3. Estabelece uma pilha para a rotina de 
tratamento de interrupção 
4. Sinaliza o controlador se interrupção (se 
houver) ou reabilita as interrupções 
5. Copia os registradores de onde foram salvos 
para a tabela de processo 
10 
Tratadores de interrupção 
6. Executa a rotina de tratamento de 
interrupção 
7. Escolhe o próximo processo a executar 
8. Estabelece o contexto da MMU para o 
próximo processo a executar 
9. Carrega os registradores do novo processo 
10. Inicia a execução do novo processo 
11 
Tratadores de interrupção 
 O processamento da interrupção está longe 
de ser trivial 
 Ela usa ainda um número considerável de 
instruções de CPU, especialmente em 
máquinas nas quais a memória virtual está 
presente e as tabelas de páginas precisam ser 
ajustadas 
12 
Drivers de dispositivos 
 Cada dispositivo de E/S ligado ao 
computador precisa de algum código 
específico do dispositivo para controlá-lo, 
chamado driver do dispositivo 
 Podemos ter um driver para cada dispositivo 
ou uma classe de dispositivos (ex: vários discos 
rígidos IDE), no entanto teclado e mouse serão 
controlados por drivers diferentes 
 Como o driver acessa diretamente o 
hardware do dispositivo ele deve ser parte do 
núcleo do SO 
13 
Drivers de dispositivos 
 Drivers mal escritos ou com bugs são a maior 
causa de crashs em sistemas 
 Dado que drivers muitas vezes são escritos por 
terceiros (fabricantes do dispositivo), o SO 
deve ter um modelo bem definido do que o 
driver faz e como ele interage com o restante 
do SO 
14 
Drivers de dispositivos 
 Posição lógica dos drivers dos dispositivos 
 A comunicação entre os drivers e os controladores de dispositivos é feita por meio do barramento 
15 
Drivers de dispositivos 
 A maioria dos SOs define uma interface 
padrão para os dispositivos de bloco e outra 
para os dispositivos de caracter 
 Estas interfaces constituem um número de 
procedimentos que o restante do SO pode 
utilizar para fazer o driver trabalhar para ele 
 Um driver possui várias funções 
 A mais óbvia é aceitar e requisitar requisições 
abstratas de leitura e gravação, de um 
software independente de dispositivo 
localizado na camada superior do SO 
16 
Drivers de dispositivos 
 Como exemplo de outra função temos a 
inicialização do dispositivo, e o tratamento de 
suas necessidades de consumo de energia 
17 
Software de E/S independente 
de dispositivo 
 A fronteira entre os drivers e SW de E/S 
independentes de dispositivos variam de 
acordo com o sistema e o próprio dispositivo 
 Porém as funções a seguir são em geral feitas 
no SW independente de dispositivo 
18 
Interface uniforme para os drivers dos dispositivos 
Armazenamento em buffer 
Relatório dos erros 
Alocação e liberação de dispositivos dedicados 
Fornecimento de tamanho de bloco independente de 
dispositivo 
Software de E/S independente 
de dispositivo 
 Interface uniforme para drivers 
 O aspecto mais importante desta questão é a 
interface entre os drivers de dispositivos e o restante 
do SO 
 Se cada driver tem uma interface diferente para o 
SO, significa que as funções do driver, disponíveis 
para serem chamada pelo sistema diferem de 
driver para driver, bem como as funções do núcleo 
requeridas pelo driver 
19 
Software de E/S independente 
de dispositivo 
 Interface uniforme para drivers 
 Quando todos os drivers tem a mesma interface é 
bem mais simples de se acoplar um novo driver, 
bastando que ele siga a interface padrão 
 Desse modo também temos uma padronização de 
quais funções um driver deve fornecer e quais 
funções do núcleo eles podem chamar 
20 
Software de E/S independente 
de dispositivo 
 
 
 
 
 
 
 
(a) Sem uma interface-padrão do driver 
(b) Com uma interface-padrão do driver 
21 
Software de E/S independente 
de dispositivo 
 Interface uniforme para drivers 
 Com a interface uniforme, o SW independente de 
dispositivo pode cuidar mais facilmente do 
mapeamento dos nomes de dispositivos simbólicos 
em seus drivers apropriados 
 EX: no UNIX todos os dispositivos do sistema são 
mapeados como arquivos especiais do diretório 
/dev 
22 
Software de E/S independente 
de dispositivo 
 Utilização de Buffers 
 É de grande importância tanto para dispositivos de 
caracter como de bloco 
 Considere um processo que deseja ler dados de um 
modem. Ele poderia realizar uma chamada ao 
sistema read e bloquear a espera de cada 
caracter 
A desvantagem deste método é que o processo do 
usuário precisa ser bloqueado e reiniciado um 
número muito grande de vezes em um curto 
intervalo de tempo, o que é ineficiente 
23 
Software de E/S independente 
de dispositivo 
 Utilização de Buffers 
 A utilização de buffer permite que o usuário forneça 
um buffer e requisite a leitura de “n” caracteres de 
uma única vez 
 O SW dependente do dispositivo coloca os 
caracteres (um a um) neste buffer até que ele 
encha. Só então ele desbloqueia o processo do 
usuário 
 Esta abordagem é bem mais eficiente que a 
anterior 
24 
Software de E/S independente 
de dispositivo 
 Utilização de Buffers 
 Na prática se utilizam soluções com mútiplos 
bufferes tanto no espaço do usuário como no 
núcleo, para aumentar ainda mais sua eficiência 
 Dado que dispositivos são geralmente muito lentos 
em relação ao resto do sistema e se há apenas um 
buffer pode-se desperdiçar caracteres quando o 
buffer está cheio 
25 
Software de E/S independente 
de dispositivo 
 Utilização de Buffers 
 
 
 
 
 
 
 
 
a) Entrada sem utilização de buffer 
b) Utilização de buffer no espaço do usuário 
c) Utilização de buffer no núcleo seguido de cópia para o espaço do 
usuário 
d) Utilização de buffer duplo no núcleo 26 
Software de E/S independente 
de dispositivo 
 Relatório de erros 
 Erros são bem mais comuns durante uma E/S que 
em qualquer outra situação 
 Quando eles ocorrem o SO deve lidar com eles da 
melhor maneira possível 
 Este tratamento pode ser desde o retorno de um 
código de erro 
 Ex: quando o usuário tenta acessar um dispositivo 
de maneira incorreta ou sem permissão 
27 
Software de E/S independente 
de dispositivo 
 Relatório de erros 
 Pode ser a exibição de uma caixa de diálogo 
perguntando ao usuário o que fazer 
 EX: no caso de um erro de leitura 
 Até a exibição de uma mensagem de erro e 
desligamento do sistema 
 Ex: No caso da destruição de uma estrutura de 
dados crítica como diretório raiz 
28 
Software de E/S independente 
de dispositivo 
 Alocação e liberação de dispositivos 
dedicados 
 Alguns dispositivos, como um gravador de CD-ROM, 
pode ser utilizado por apenas um único processo 
por vez 
 O SO deve ser capaz de examinar as requisições de 
uso do dispositivo, podendo aceitá-las ou rejeitá-las, 
dependendo da disponibilidade do dispositivo 
29 
Software de E/S independente 
de dispositivo 
 Alocação e liberação de dispositivos 
dedicados 
 Quando um dispositivo dedicado já está sendo 
utilizado por um processo e outro processo tenta 
acessá-lo o SO pode retornar uma falha 
 Uma alternativa é bloquear o processo requisitante 
e colocá-lo em uma fila, de modo que quando o 
dispositivo estiver disponível novamente o primeiro 
processo da fila terá acesso ao dispositivo 
30 
Software de E/S independente 
de dispositivo 
 Tamanho de bloco independente de 
dispositivo 
 Discos diferentes tem tamanhos diferentes de 
setores 
 É função do SW independente de dispositivo 
esconder este detalhe e fornecer um tamanho de 
bloco uniforme para as camadas superiores 
 Do mesmo modo que alguns dispositivos de 
caracter entregam um byte por vez (como 
modem), enquanto outros entregam dado em 
unidades maiores (interfaces de rede) 
 Estas diferenças também devem ser ocultadas 
31 
Software de E/S do espaço do 
usuário 
 Embora a maior parte do SW de E/S esteja 
dentro do SO, uma pequena parte dele é 
construída de bibliotecas 
 Programas de usuários normalmente fazem 
uso de diversos procedimentos 
disponibilizados por estas bibliotecas, que por 
sua vez realizam as chamadas reais ao 
sistema 
 Um exemplo clássico são as bibliotecas C 
padrões, onde estão os procedimentos: open, 
read, write, printf, scanf, entre outros 
32 
Software de E/S do espaço do 
usuário 
 Outra categoria importante é o sistema de 
spooling, uma maneira de lidar com 
dispositivos de E/S dedicados em sistemas 
com multiprogramação 
 Num exemplo clássico (impressora) é criado 
um processo especial, chamado de daemon, 
e um diretório especial, chamado spool 
 Para imprimir um arquivo o processo de 
usuário deve gerar todo o arquivo a ser 
impresso e o copiar para o diretório de spool 
33 
Software de E/S do espaço do 
usuário 
 Fica a cardo do daemon (único a poder se 
utilizar do arquivo especial da impressora) 
imprimir os arquivos do diretório 
 A figura a seguir resume todo os sistema de 
E/S, mostrando as camadas e as funções 
principais de cada uma delas 
34 
Software de E/S do espaço do 
usuário 
 Camadas do sistema de E/S e as principais 
funções de cada camada 
35 
Referências 
 TANENBAUM, Andrew S. Sistemas Operacionais 
Modernos. 2. ed., Prentice Hall, 2007. 
 TANENBAUM, Andrew S.; WOODHULL, Albert S. 
Sistemas Operacionais: Projeto e 
Implementação. 3ª Ed., Prentice Hall, 2008. 
36