SlideShare une entreprise Scribd logo
1  sur  28
QNX RTOS
Lucas Casagrande e Daniel Carlos
APRESENTAÇÃO
Introdução ao QNX.
Gerenciamento de Processos.
Gerenciamento de Memória.
Gerenciamento de I/O.
Sistemas de Arquivos.
Conclusões.
Tempo Real
Multitarefa
Destinado a Sistemas
Embarcados
Arquitetura
Microkernel
Multiusuário
Baseado no UNIX
QNX...
*Introdução ao QNX
QNX...
Começou do trabalho de dois universitários da Universidade de Waterloo.
Lançada Primeira Versão em 1982.
Primeira utilização foi no sistema de educação da Universidade de Ontario.
Lançado o QNX4 para atender as normas do POSIX no final da década de 1980.
Em 1990 começou o desenvolvimento do QNX Neutrino.
Em 2004 a companhia foi comprada pela Harman International Industries.
Em 2010 foi comprada pelo Research In Motion da BlackBerry.
Lançado o BlackBerry Tablet OS e o BlackBerry Playbook baseados no kernel do QNX.
*Introdução ao QNX
QNX
*Introdução ao QNX
Atualmente
QNX Neutrino RTOS
QNX OS for Automotive Safety
QNX OS for Medical
QNX OS for Security
QNX OS for Safety
APLICABILIDADE
*Introdução ao QNX
Porque QNX é tão utilizado?
 Verdadeiro Design de Microkernel.
 Provê apenas as funcionalidades mínimas.
 Permite a substituição de drivers, implementação de sistemas de
arquivos, adição de módulos sem a necessidade de uma
reinicialização.
 Em causa de falhas o sistema não é todo comprometido.
 Simplicidade.
 Fácil de dar manutenção e customizar.
Comparação entre arquiteturas
REAL TIME EXECUTIVE
Advantage: single address space
Disadvantage: single address space,
different binary images
Failure: means reboot
MONOLITHIC KERNEL
Advantage: apps run in own memory space
Disadvantage: kernel not protected,
kernel testing
Failure: might mean reboot
TRUE MICROKERNEL
Advantage
Modules run in own memory space
Add/replace services on the fly
Reusable modules
Direct hardware access
Disadvantage: context switching
Failure: usually does not mean reboot
*Introdução ao QNX
Arquitetura do QNX Neutrino RTOS
*Introdução ao QNX
No QNX, a maioria dos serviços de tempo real são implementadas no kernel.
Semáforos e mutexes se encontram em nível de kernel.
Serviços em que o kernel é dedicado:
− Serviços de thread.
− Serviços de sinais.
− Serviços de troca de mensagens na comunicação entre processos.
− Serviços de sincronização de threads.
− Serviços de escalonamento.
− Serviços de tempo.
− Serviços de gerenciamento de processos.
Gerenciamento de Processos
Por dentro do QNX
*Gerenciamento de Processos
No gerenciamento de processos
tem-se duas funções principais:
− Comunicação entre Processos
− Escalonamento
*Gerenciamento de Processos
Comunicação entre Processos
►Gerenciado pelo IPC (Interprocess Communication).
►Responsável por interligar todo o SO.
►Entre as principais formas de IPC, tem-se:
→ Oferecem uma
comunicação síncrona
entre os processos.
→ Principal forma de
comunicação.
→ Utiliza funções da
linguagem C.
→ Importante por garantir
maior desempenho na
execução das threads.
→ Forma de mensagem
não bloqueante.
→ Adequada para
notificação de eventos.
→ Forma tradicional de
comunicação.
→ Utilizado para suportar
comunicação assíncrona.
- Troca de Mensagens - Proxies - Sinais
*Gerenciamento de Processos
Comunicação entre Processos
Exemplos
Mensagem Proxies
*Gerenciamento de Processos
Politicas de Escalonamento
►O QNX Implementa três tipos:
− FIFO
− ROUND ROBIN
− SPORADIC
→ First In First Out Preemptivo.
→ Processo fica na CPU até:
− Terminar sua execução.
− Ficar bloqueado.
− Processo de maior prioridade
esteja pronto.
→ Round Robin Preemptivo.
→ Processo fica na CPU até:
− Terminar sua execução.
− Ficar bloqueado.
− Processo de maior prioridade
esteja pronto.
− Expire o tempo de execução.
*Gerenciamento de Processos
Politicas de Escalonamento
→ Utilizado para fornecer um limite nivelado
de tempo de execução, dentro um periodo
determinado.
→ Permite que uma thread atenda a eventos
não periódicos sem prejudicar o deadline
de outras threads.
→ Emprega um “saldo” para a execução de
uma thread
SPORADIC SCHEDULER
R: Saldo consumido durante a execução.
C: Saldo estimado para execução.
T: Tempo para o saldo ser reabastecido.
*Gerenciamento de Processos
Níveis de Prioridade
Níveis de Prioridade no QNX
► Os níveis de prioridade do QNX, podem variar em
um total de 256 níveis de prioridade.
► Threads sem privilégios podem definir sua prioridade
a um nível de 1 a 63, independente da política de
escalonamento utilizada.
► Contudo, é possível alterar esta restrição para threads
sem privilégios, tendo-se as devidas precauções.
A unidade de gerenciamento de memória no QNX é conhecida como MMU.
A MMU é responsável por:
− Fornecer proteção completa a memória.
− Abortar um processo no instante que a memória é violada.
− Assegurar que as falhas fiquem confinados aos programas que a causaram.
− Isolar os processos entre si e entre os processos do kernel.
− Dividir a memória física em paginas geralmente de 4Kb.
Gerenciamento de Memória
Memória Virtual
Mapeamento da memória virtual
*Gerenciamento de Memória
► A MMU começa por dividindo a memória
física em paginas de 4kb.
► Então o processador usa um conjunto de
tabelas de páginas que definem o
mapeamento de endereços
virtuais para acessar a memória física
► Enquanto a thread executa, as tabelas de
paginas controladas pelo SO controla
como os endereços de memória que estão
sendo usados, são mapeados para a
memória física.
► Se uma thread tenta acessar um endereço
não mapeado para ele, a CPU irá receber
um erro em um tipo especial de interrupção.
Watchdog
*Gerenciamento de Memória
► QNX Implementa um software de Watchdog.
► Detecta se uma thread parou de funcionar e toma as devidas providencias.
► Ao contrario do hardware de Watchdog, permite a recuperação do sistema sem a
reinicialização.
► Quando ocorre uma falha, o software de Watchdog pode:
− Abortar o processo que falhou e simplesmente reiniciar o processo sem
comprometer todo o sistema.
− Abortar o processo que falhou e todos os outros relacionados, inicializar o
hardware em um estado seguro e depois reiniciar todos os processos
novamente.
− Em casos estremos, se a falha é muito crítica, ele desliga
coordenamente o sistema e faz soar um alarme sonoro.
Watchdog
*Gerenciamento de Memória
Exemplo
Watchdog
*Gerenciamento de Memória
Exemplo 2
No QNX, os recursos de I/O não são implementados no microkernel.
São fornecidos por processos do gerenciador de recursos que
podem ser iniciados dinamicamente em tempo de execução.
O gerenciador de recursos é um programa a nível de usuário que
pode ser explicado como uma interface para vários tipos de
dispositivos.
Gerenciamento de I/O
A sua utilização é opcional.
IO-CHAR Library
*Gerenciamento de I/O
IO-Char implementado como uma biblioteca
► O qnx fornece uma família de drivers e
uma biblioteca chamada de io-char
para maximizar o reuso de código.
► O módulo io-char contém todo o código
para suportar os padrões da POSIX e
tudo que é desejável em sistemas de
tempo real.
► Com um único módulo, o custo de
memória em adicionar novos dispositivos
é mínimo, sendo somente necessário
implementar um novo driver.
*Lembrando que drivers no QNX são processos
de usuário e possuem as mesmas prioridades
que tais.
IO-CHAR Library
*Gerenciamento de I/O
Exemplo
► O fluxo de dados entre a biblioteca e os drivers,
ocorrem através de um conjunto de filas na
memória associadas a cada dispositivo de I/O.
► Um número de três filas são utilizadas em cada
dispositivo, e cada fila é implementada utilizado
a politica FIFO.
► Os dados recebidos são colocados na fila de
input e é consumido pela biblioteca somente
quando os processos das aplicações solicitarem
► Os dados de saída são colocados pelo io-char
na fila de saída para serem processados pelos
drivers.
► A fila canonical é utilizada enquanto estiver
sendo processado dados de entrada em modo
de edição
Dispositivos I/O no QNX Neutrino RTOS.
Assim como nos dispositivos de I/O, os sistemas de arquivos são executados
como processos ao nível de usuário.
Se comunicam com as aplicações através de mensagens geradas por uma
biblioteca compartilhada implementada na API.
Muitos dos sistemas de arquivos são gerenciadores de recursos, onde ele
acaba por se tornar uma interface para as aplicações gravarem
informações no disco
Sistemas de Arquivos
O responsável por manter os caminhos (arvore) do pathname é o procnto
(unidade que compõem o kernel e o gerenciador de processos).
Tipos de Sistemas de Arquivos
*Sistemas de Arquivos
Conclusões...
QNX RTOS Introdução

Contenu connexe

Tendances

DDS: The IoT Data Sharing Standard
DDS: The IoT Data Sharing StandardDDS: The IoT Data Sharing Standard
DDS: The IoT Data Sharing StandardAngelo Corsaro
 
OpenStack概要 ~仮想ネットワーク~
OpenStack概要 ~仮想ネットワーク~OpenStack概要 ~仮想ネットワーク~
OpenStack概要 ~仮想ネットワーク~Masaya Aoyama
 
Message Signaled Interrupts
Message Signaled InterruptsMessage Signaled Interrupts
Message Signaled InterruptsAnshuman Biswal
 
5ステップで始めるPostgreSQLレプリケーション@hbstudy#13
5ステップで始めるPostgreSQLレプリケーション@hbstudy#135ステップで始めるPostgreSQLレプリケーション@hbstudy#13
5ステップで始めるPostgreSQLレプリケーション@hbstudy#13Uptime Technologies LLC (JP)
 
Rootlinux17: An introduction to Xen Project Virtualisation
Rootlinux17:  An introduction to Xen Project VirtualisationRootlinux17:  An introduction to Xen Project Virtualisation
Rootlinux17: An introduction to Xen Project VirtualisationThe Linux Foundation
 
エンジニアなら知っておきたい「仮想マシン」のしくみ (BPStudy38)
エンジニアなら知っておきたい「仮想マシン」のしくみ (BPStudy38)エンジニアなら知っておきたい「仮想マシン」のしくみ (BPStudy38)
エンジニアなら知っておきたい「仮想マシン」のしくみ (BPStudy38)Takeshi HASEGAWA
 
Linux container, namespaces & CGroup.
Linux container, namespaces & CGroup. Linux container, namespaces & CGroup.
Linux container, namespaces & CGroup. Neeraj Shrimali
 
The TCP/IP Stack in the Linux Kernel
The TCP/IP Stack in the Linux KernelThe TCP/IP Stack in the Linux Kernel
The TCP/IP Stack in the Linux KernelDivye Kapoor
 
Núcleo do Linux (Kernel Linux)
Núcleo do Linux (Kernel Linux)Núcleo do Linux (Kernel Linux)
Núcleo do Linux (Kernel Linux)Luiz Arthur
 
Neutron-to-Neutron: interconnecting multiple OpenStack deployments
Neutron-to-Neutron: interconnecting multiple OpenStack deploymentsNeutron-to-Neutron: interconnecting multiple OpenStack deployments
Neutron-to-Neutron: interconnecting multiple OpenStack deploymentsThomas Morin
 
4章 Linuxカーネル - 割り込み・例外 5
4章 Linuxカーネル - 割り込み・例外 54章 Linuxカーネル - 割り込み・例外 5
4章 Linuxカーネル - 割り込み・例外 5mao999
 
introduction to linux kernel tcp/ip ptocotol stack
introduction to linux kernel tcp/ip ptocotol stack introduction to linux kernel tcp/ip ptocotol stack
introduction to linux kernel tcp/ip ptocotol stack monad bobo
 
Telco Cloud 01 - Introduction to NFV
Telco Cloud 01 - Introduction to NFVTelco Cloud 01 - Introduction to NFV
Telco Cloud 01 - Introduction to NFVVikas Shokeen
 
CCIS Chapter 6 Openstack new.pptx
CCIS  Chapter  6  Openstack new.pptxCCIS  Chapter  6  Openstack new.pptx
CCIS Chapter 6 Openstack new.pptxSanaLatif13
 
POR DENTRO DO DATACENTER
POR DENTRO DO DATACENTERPOR DENTRO DO DATACENTER
POR DENTRO DO DATACENTERFelipe Matheus
 
第4回Linux-HA勉強会資料 Pacemakerの紹介
第4回Linux-HA勉強会資料 Pacemakerの紹介第4回Linux-HA勉強会資料 Pacemakerの紹介
第4回Linux-HA勉強会資料 Pacemakerの紹介ksk_ha
 

Tendances (20)

Qnx os
Qnx osQnx os
Qnx os
 
Qnx
QnxQnx
Qnx
 
DDS: The IoT Data Sharing Standard
DDS: The IoT Data Sharing StandardDDS: The IoT Data Sharing Standard
DDS: The IoT Data Sharing Standard
 
OpenStack概要 ~仮想ネットワーク~
OpenStack概要 ~仮想ネットワーク~OpenStack概要 ~仮想ネットワーク~
OpenStack概要 ~仮想ネットワーク~
 
Message Signaled Interrupts
Message Signaled InterruptsMessage Signaled Interrupts
Message Signaled Interrupts
 
5ステップで始めるPostgreSQLレプリケーション@hbstudy#13
5ステップで始めるPostgreSQLレプリケーション@hbstudy#135ステップで始めるPostgreSQLレプリケーション@hbstudy#13
5ステップで始めるPostgreSQLレプリケーション@hbstudy#13
 
Rootlinux17: An introduction to Xen Project Virtualisation
Rootlinux17:  An introduction to Xen Project VirtualisationRootlinux17:  An introduction to Xen Project Virtualisation
Rootlinux17: An introduction to Xen Project Virtualisation
 
Clear Linux OS - Introduction
Clear Linux OS - IntroductionClear Linux OS - Introduction
Clear Linux OS - Introduction
 
エンジニアなら知っておきたい「仮想マシン」のしくみ (BPStudy38)
エンジニアなら知っておきたい「仮想マシン」のしくみ (BPStudy38)エンジニアなら知っておきたい「仮想マシン」のしくみ (BPStudy38)
エンジニアなら知っておきたい「仮想マシン」のしくみ (BPStudy38)
 
Linux container, namespaces & CGroup.
Linux container, namespaces & CGroup. Linux container, namespaces & CGroup.
Linux container, namespaces & CGroup.
 
The TCP/IP Stack in the Linux Kernel
The TCP/IP Stack in the Linux KernelThe TCP/IP Stack in the Linux Kernel
The TCP/IP Stack in the Linux Kernel
 
Núcleo do Linux (Kernel Linux)
Núcleo do Linux (Kernel Linux)Núcleo do Linux (Kernel Linux)
Núcleo do Linux (Kernel Linux)
 
Neutron-to-Neutron: interconnecting multiple OpenStack deployments
Neutron-to-Neutron: interconnecting multiple OpenStack deploymentsNeutron-to-Neutron: interconnecting multiple OpenStack deployments
Neutron-to-Neutron: interconnecting multiple OpenStack deployments
 
4章 Linuxカーネル - 割り込み・例外 5
4章 Linuxカーネル - 割り込み・例外 54章 Linuxカーネル - 割り込み・例外 5
4章 Linuxカーネル - 割り込み・例外 5
 
introduction to linux kernel tcp/ip ptocotol stack
introduction to linux kernel tcp/ip ptocotol stack introduction to linux kernel tcp/ip ptocotol stack
introduction to linux kernel tcp/ip ptocotol stack
 
Telco Cloud 01 - Introduction to NFV
Telco Cloud 01 - Introduction to NFVTelco Cloud 01 - Introduction to NFV
Telco Cloud 01 - Introduction to NFV
 
Veeam backup and_replication
Veeam backup and_replicationVeeam backup and_replication
Veeam backup and_replication
 
CCIS Chapter 6 Openstack new.pptx
CCIS  Chapter  6  Openstack new.pptxCCIS  Chapter  6  Openstack new.pptx
CCIS Chapter 6 Openstack new.pptx
 
POR DENTRO DO DATACENTER
POR DENTRO DO DATACENTERPOR DENTRO DO DATACENTER
POR DENTRO DO DATACENTER
 
第4回Linux-HA勉強会資料 Pacemakerの紹介
第4回Linux-HA勉強会資料 Pacemakerの紹介第4回Linux-HA勉強会資料 Pacemakerの紹介
第4回Linux-HA勉強会資料 Pacemakerの紹介
 

Similaire à QNX RTOS Introdução

Linux Containers: do que são feitos? de onde vem? quem os alimenta?
Linux Containers: do que são feitos? de onde vem? quem os alimenta?Linux Containers: do que são feitos? de onde vem? quem os alimenta?
Linux Containers: do que são feitos? de onde vem? quem os alimenta?Marcos Paulo de Souza
 
Sistema Operacional de Tempo Real (vx works)
Sistema Operacional de Tempo Real (vx works)Sistema Operacional de Tempo Real (vx works)
Sistema Operacional de Tempo Real (vx works)Jose Silva
 
Sistema Operacional de Tempo Real(vx works)
Sistema Operacional de Tempo Real(vx works)Sistema Operacional de Tempo Real(vx works)
Sistema Operacional de Tempo Real(vx works)Jose Silva
 
Apresentação Monografia
Apresentação MonografiaApresentação Monografia
Apresentação MonografiaLeon Homar
 
Introdução aos sistemas operacionais embarcados
Introdução aos sistemas operacionais embarcadosIntrodução aos sistemas operacionais embarcados
Introdução aos sistemas operacionais embarcadosRodrigo Almeida
 
Material Auxiliar Para Curso BáSico Msp430 1 A 54
Material Auxiliar Para Curso BáSico Msp430   1 A 54Material Auxiliar Para Curso BáSico Msp430   1 A 54
Material Auxiliar Para Curso BáSico Msp430 1 A 54Texas Instruments
 
Coroutine e concorrência python
Coroutine e concorrência   python Coroutine e concorrência   python
Coroutine e concorrência python Kaueh Moreno
 
Máquinas Multiníveis - Nível da Microarquitetura
Máquinas Multiníveis - Nível da MicroarquiteturaMáquinas Multiníveis - Nível da Microarquitetura
Máquinas Multiníveis - Nível da MicroarquiteturaLincoln Lamas
 
TDC2016SP - Trilha Linux Embarcado
TDC2016SP - Trilha Linux EmbarcadoTDC2016SP - Trilha Linux Embarcado
TDC2016SP - Trilha Linux Embarcadotdc-globalcode
 
Amazon EC2 boas praticas e otimizações de desempenho
Amazon EC2 boas praticas e otimizações de desempenhoAmazon EC2 boas praticas e otimizações de desempenho
Amazon EC2 boas praticas e otimizações de desempenhoAmazon Web Services LATAM
 

Similaire à QNX RTOS Introdução (20)

Seminário QNX
Seminário QNXSeminário QNX
Seminário QNX
 
Embarcados
EmbarcadosEmbarcados
Embarcados
 
Unix - Robert
Unix - RobertUnix - Robert
Unix - Robert
 
Unix - Sistema Operacional
Unix - Sistema OperacionalUnix - Sistema Operacional
Unix - Sistema Operacional
 
Snort
SnortSnort
Snort
 
Linux Containers: do que são feitos? de onde vem? quem os alimenta?
Linux Containers: do que são feitos? de onde vem? quem os alimenta?Linux Containers: do que são feitos? de onde vem? quem os alimenta?
Linux Containers: do que são feitos? de onde vem? quem os alimenta?
 
Sistema Operacional de Tempo Real (vx works)
Sistema Operacional de Tempo Real (vx works)Sistema Operacional de Tempo Real (vx works)
Sistema Operacional de Tempo Real (vx works)
 
Sistema Operacional de Tempo Real(vx works)
Sistema Operacional de Tempo Real(vx works)Sistema Operacional de Tempo Real(vx works)
Sistema Operacional de Tempo Real(vx works)
 
Apresentação Monografia
Apresentação MonografiaApresentação Monografia
Apresentação Monografia
 
Minix
MinixMinix
Minix
 
Introdução aos sistemas operacionais embarcados
Introdução aos sistemas operacionais embarcadosIntrodução aos sistemas operacionais embarcados
Introdução aos sistemas operacionais embarcados
 
Material Auxiliar Para Curso BáSico Msp430 1 A 54
Material Auxiliar Para Curso BáSico Msp430   1 A 54Material Auxiliar Para Curso BáSico Msp430   1 A 54
Material Auxiliar Para Curso BáSico Msp430 1 A 54
 
Cluster
ClusterCluster
Cluster
 
Trabalho sistemas operacionais
Trabalho sistemas operacionaisTrabalho sistemas operacionais
Trabalho sistemas operacionais
 
Coroutine e concorrência python
Coroutine e concorrência   python Coroutine e concorrência   python
Coroutine e concorrência python
 
Máquinas Multiníveis - Nível da Microarquitetura
Máquinas Multiníveis - Nível da MicroarquiteturaMáquinas Multiníveis - Nível da Microarquitetura
Máquinas Multiníveis - Nível da Microarquitetura
 
TDC2016SP - Trilha Linux Embarcado
TDC2016SP - Trilha Linux EmbarcadoTDC2016SP - Trilha Linux Embarcado
TDC2016SP - Trilha Linux Embarcado
 
Amazon EC2 boas praticas e otimizações de desempenho
Amazon EC2 boas praticas e otimizações de desempenhoAmazon EC2 boas praticas e otimizações de desempenho
Amazon EC2 boas praticas e otimizações de desempenho
 
Gts flowtools
Gts flowtoolsGts flowtools
Gts flowtools
 
Apresentacao sobre o KURT
Apresentacao sobre o KURTApresentacao sobre o KURT
Apresentacao sobre o KURT
 

QNX RTOS Introdução

  • 1. QNX RTOS Lucas Casagrande e Daniel Carlos
  • 2. APRESENTAÇÃO Introdução ao QNX. Gerenciamento de Processos. Gerenciamento de Memória. Gerenciamento de I/O. Sistemas de Arquivos. Conclusões.
  • 3. Tempo Real Multitarefa Destinado a Sistemas Embarcados Arquitetura Microkernel Multiusuário Baseado no UNIX QNX... *Introdução ao QNX
  • 4. QNX... Começou do trabalho de dois universitários da Universidade de Waterloo. Lançada Primeira Versão em 1982. Primeira utilização foi no sistema de educação da Universidade de Ontario. Lançado o QNX4 para atender as normas do POSIX no final da década de 1980. Em 1990 começou o desenvolvimento do QNX Neutrino. Em 2004 a companhia foi comprada pela Harman International Industries. Em 2010 foi comprada pelo Research In Motion da BlackBerry. Lançado o BlackBerry Tablet OS e o BlackBerry Playbook baseados no kernel do QNX. *Introdução ao QNX
  • 5. QNX *Introdução ao QNX Atualmente QNX Neutrino RTOS QNX OS for Automotive Safety QNX OS for Medical QNX OS for Security QNX OS for Safety
  • 7. *Introdução ao QNX Porque QNX é tão utilizado?  Verdadeiro Design de Microkernel.  Provê apenas as funcionalidades mínimas.  Permite a substituição de drivers, implementação de sistemas de arquivos, adição de módulos sem a necessidade de uma reinicialização.  Em causa de falhas o sistema não é todo comprometido.  Simplicidade.  Fácil de dar manutenção e customizar.
  • 8. Comparação entre arquiteturas REAL TIME EXECUTIVE Advantage: single address space Disadvantage: single address space, different binary images Failure: means reboot MONOLITHIC KERNEL Advantage: apps run in own memory space Disadvantage: kernel not protected, kernel testing Failure: might mean reboot TRUE MICROKERNEL Advantage Modules run in own memory space Add/replace services on the fly Reusable modules Direct hardware access Disadvantage: context switching Failure: usually does not mean reboot *Introdução ao QNX
  • 9. Arquitetura do QNX Neutrino RTOS *Introdução ao QNX
  • 10. No QNX, a maioria dos serviços de tempo real são implementadas no kernel. Semáforos e mutexes se encontram em nível de kernel. Serviços em que o kernel é dedicado: − Serviços de thread. − Serviços de sinais. − Serviços de troca de mensagens na comunicação entre processos. − Serviços de sincronização de threads. − Serviços de escalonamento. − Serviços de tempo. − Serviços de gerenciamento de processos. Gerenciamento de Processos
  • 11. Por dentro do QNX *Gerenciamento de Processos No gerenciamento de processos tem-se duas funções principais: − Comunicação entre Processos − Escalonamento
  • 12. *Gerenciamento de Processos Comunicação entre Processos ►Gerenciado pelo IPC (Interprocess Communication). ►Responsável por interligar todo o SO. ►Entre as principais formas de IPC, tem-se: → Oferecem uma comunicação síncrona entre os processos. → Principal forma de comunicação. → Utiliza funções da linguagem C. → Importante por garantir maior desempenho na execução das threads. → Forma de mensagem não bloqueante. → Adequada para notificação de eventos. → Forma tradicional de comunicação. → Utilizado para suportar comunicação assíncrona. - Troca de Mensagens - Proxies - Sinais
  • 13. *Gerenciamento de Processos Comunicação entre Processos Exemplos Mensagem Proxies
  • 14. *Gerenciamento de Processos Politicas de Escalonamento ►O QNX Implementa três tipos: − FIFO − ROUND ROBIN − SPORADIC → First In First Out Preemptivo. → Processo fica na CPU até: − Terminar sua execução. − Ficar bloqueado. − Processo de maior prioridade esteja pronto. → Round Robin Preemptivo. → Processo fica na CPU até: − Terminar sua execução. − Ficar bloqueado. − Processo de maior prioridade esteja pronto. − Expire o tempo de execução.
  • 15. *Gerenciamento de Processos Politicas de Escalonamento → Utilizado para fornecer um limite nivelado de tempo de execução, dentro um periodo determinado. → Permite que uma thread atenda a eventos não periódicos sem prejudicar o deadline de outras threads. → Emprega um “saldo” para a execução de uma thread SPORADIC SCHEDULER R: Saldo consumido durante a execução. C: Saldo estimado para execução. T: Tempo para o saldo ser reabastecido.
  • 16. *Gerenciamento de Processos Níveis de Prioridade Níveis de Prioridade no QNX ► Os níveis de prioridade do QNX, podem variar em um total de 256 níveis de prioridade. ► Threads sem privilégios podem definir sua prioridade a um nível de 1 a 63, independente da política de escalonamento utilizada. ► Contudo, é possível alterar esta restrição para threads sem privilégios, tendo-se as devidas precauções.
  • 17. A unidade de gerenciamento de memória no QNX é conhecida como MMU. A MMU é responsável por: − Fornecer proteção completa a memória. − Abortar um processo no instante que a memória é violada. − Assegurar que as falhas fiquem confinados aos programas que a causaram. − Isolar os processos entre si e entre os processos do kernel. − Dividir a memória física em paginas geralmente de 4Kb. Gerenciamento de Memória
  • 18. Memória Virtual Mapeamento da memória virtual *Gerenciamento de Memória ► A MMU começa por dividindo a memória física em paginas de 4kb. ► Então o processador usa um conjunto de tabelas de páginas que definem o mapeamento de endereços virtuais para acessar a memória física ► Enquanto a thread executa, as tabelas de paginas controladas pelo SO controla como os endereços de memória que estão sendo usados, são mapeados para a memória física. ► Se uma thread tenta acessar um endereço não mapeado para ele, a CPU irá receber um erro em um tipo especial de interrupção.
  • 19. Watchdog *Gerenciamento de Memória ► QNX Implementa um software de Watchdog. ► Detecta se uma thread parou de funcionar e toma as devidas providencias. ► Ao contrario do hardware de Watchdog, permite a recuperação do sistema sem a reinicialização. ► Quando ocorre uma falha, o software de Watchdog pode: − Abortar o processo que falhou e simplesmente reiniciar o processo sem comprometer todo o sistema. − Abortar o processo que falhou e todos os outros relacionados, inicializar o hardware em um estado seguro e depois reiniciar todos os processos novamente. − Em casos estremos, se a falha é muito crítica, ele desliga coordenamente o sistema e faz soar um alarme sonoro.
  • 22. No QNX, os recursos de I/O não são implementados no microkernel. São fornecidos por processos do gerenciador de recursos que podem ser iniciados dinamicamente em tempo de execução. O gerenciador de recursos é um programa a nível de usuário que pode ser explicado como uma interface para vários tipos de dispositivos. Gerenciamento de I/O A sua utilização é opcional.
  • 23. IO-CHAR Library *Gerenciamento de I/O IO-Char implementado como uma biblioteca ► O qnx fornece uma família de drivers e uma biblioteca chamada de io-char para maximizar o reuso de código. ► O módulo io-char contém todo o código para suportar os padrões da POSIX e tudo que é desejável em sistemas de tempo real. ► Com um único módulo, o custo de memória em adicionar novos dispositivos é mínimo, sendo somente necessário implementar um novo driver. *Lembrando que drivers no QNX são processos de usuário e possuem as mesmas prioridades que tais.
  • 24. IO-CHAR Library *Gerenciamento de I/O Exemplo ► O fluxo de dados entre a biblioteca e os drivers, ocorrem através de um conjunto de filas na memória associadas a cada dispositivo de I/O. ► Um número de três filas são utilizadas em cada dispositivo, e cada fila é implementada utilizado a politica FIFO. ► Os dados recebidos são colocados na fila de input e é consumido pela biblioteca somente quando os processos das aplicações solicitarem ► Os dados de saída são colocados pelo io-char na fila de saída para serem processados pelos drivers. ► A fila canonical é utilizada enquanto estiver sendo processado dados de entrada em modo de edição Dispositivos I/O no QNX Neutrino RTOS.
  • 25. Assim como nos dispositivos de I/O, os sistemas de arquivos são executados como processos ao nível de usuário. Se comunicam com as aplicações através de mensagens geradas por uma biblioteca compartilhada implementada na API. Muitos dos sistemas de arquivos são gerenciadores de recursos, onde ele acaba por se tornar uma interface para as aplicações gravarem informações no disco Sistemas de Arquivos O responsável por manter os caminhos (arvore) do pathname é o procnto (unidade que compõem o kernel e o gerenciador de processos).
  • 26. Tipos de Sistemas de Arquivos *Sistemas de Arquivos