Sistemas de Informação. Sistemas Operacionais

Transcrição

1 Sistemas de Informação Sistemas Operacionais

2 PROCESSOS E THREADS PARTE II SUMÁRIO 3. THREAD: 3.1 Introdução; 3.2 Ambiente Monothread; 3.3 Ambiente Multithread; 3.4 Arquitetura e Implementação; 3.5 Modelos de Programação.

3 3.1 Introdução Até o final da década de 1970, os sistemas operacionais suportavam apenas processos com um único thread (monothread). A partir do conceito de múltiplos threads (multithread) é possível projetar e implementar aplicações concorrentes de forma eficiente. Existem diferentes modelos para a implementação de threads em um SO, onde desempenho, flexibilidade e custo devem ser avaliados. Atualmente, o conceito de multithread pode ser encontrado em diversos SOs, em função do aumento de popularidade dos sistemas com múltiplos processadores, do modelo cliente-servidor e dos sistemas distribuídos.

4 3.1 Introdução Thread é um pequeno programa que trabalha como um subsistema, sendo uma forma de um processo se autodividir em duas ou mais tarefas. É o termo em inglês para Linha ou Encadeamento de Execução. Essas tarefas múltiplas podem ser executadas simultaneamente para rodar mais rápido do que um programa em um único bloco ou praticamente juntas, mas que são tão rápidas que parecem estar trabalhando em conjunto ao mesmo tempo.

5 3.1 Introdução Porque Thread? Simplificam modelo de programação: em muitas aplicações há múltiplas atividades ao mesmo tempo: múltiplos threads sequenciais que executam em quase-paralelo; Fáceis de criar e destruir: sem recursos associados, é mais rápido que criar e destruir processos; Aceleram aplicação: conveniente quando há grande quantidade de E/S e de computação, as atividades se sobrepõem.

6 3.2 Ambiente Monothread Neste ambiente, um processo suporta apenas um programa no seu espaço de endereçamento. Dessa forma, as aplicações concorrentes são implementadas apenas com o uso de múltiplos processos independentes ou subprocessos. Problemas: O uso de processos no desenvolvimento de aplicações concorrentes demanda consumo de diversos recursos do sistema; O compartilhamento do espaço de endereçamento e de recursos comuns aos processos concorrentes.

7 3.2 Ambiente Monothread Subprocessos Processos Independentes

8 3.2 Ambiente Monothread Thread Thread Thread

9 3.3 Ambiente Multithread Neste ambiente, com múltiplos threads, não existe a ideia de programas associados a processos, mas, sim, a threads. Threads compartilham o processador da mesma maneira que processos e passam pelas mesmas mudanças de estado (espera, pronto e execução). Dentro de um mesmo processo, threads compartilham o mesmo contexto de software e espaço de endereçamento com os demais threads, porém cada thread possui seu contexto de hardware individual.

10 3.3 Ambiente Multithread Contexto de hardware Contexto de hardware Contexto de hardware Contexto de software Thread 1 Thread 2 Espaço de endereçamento Thread 3

11 3.3 Ambiente Multithread Processo Espaço de endereçamento... Variáveis Programa Principal Call Sub_1 Thread_1 PC SP Contexto de Hardware Call Sub_2 Fim Sub_1 Thread_2 PC SP Contexto de Hardware Ret Sub_2 Thread_3 PC SP Contexto de Hardware Ret...

12 3.3 Ambiente Multithread Threads são implementados através de uma estrutura de dados, denominada bloco de controle do thread (Thread Control Block - TCB). O TCB armazena, além do contexto do hardware, mais algumas informações relacionadas ao thread. Em um ambiente monothread, o processo é ao mesmo tempo a unidade de alocação de recursos e a unidade de escalonamento. Em um ambiente multithread, a unidade de alocação de recursos é o processo e cada thread representa uma unidade de escalonamento independente.

13 3.3 Ambiente Multithread A grande diferença entre aplicações monothread e multithread está no uso do espaço de endereçamento. Programas concorrentes com múltiplos threads são mais rápidos do que implementados com múltiplos processos. Vantagens: Operações de criação, troca de contexto e eliminação dos threads geram menor overhead (processamento ou armazenamento em excesso); Comunicação entre threads pode ser realizada de forma rápida e eficiente, na qual podem compartilhar facilmente outros recursos em um mesmo processo. Não deixam o processo parado, pois quando um deles está aguardando um determinado dispositivo de entrada ou saída, ou ainda outro recurso do sistema, outro thread pode estar trabalhando.

14 3.3 Ambiente Multithread Thread de entrada Buffer Thread de exibição Thread de gravação

15 3.3 Ambiente Multithread Em ambientes cliente-servidor, threads são essenciais para solicitações de serviços remotos. Em um ambiente multithread, um thread pode solicitar o serviço remoto, enquanto a aplicação pode continuar realizando outras atividades. Para o processo que atende a solicitação, múltiplos threads permitem que diversos pedidos sejam atendidos simultaneamente. O núcleo do sistema também pode ser implementado em um ambiente multithread.

16 3.3 Ambiente Multithread Processo servidor Solicitações Thread Thread Thread Processo cliente Processo cliente Processo cliente

17 3.4 Arquitetura e Implementação Threads podem ser oferecidos por uma biblioteca de rotinas fora do núcleo do SO (modo usuário), pelo próprio núcleo do sistema (modo kernel), por uma combinação de ambos (modo híbrido) ou por um modelo conhecido como scheduler activations.

18 3.4.1 Threads em Modo Usuário TMU são implementados pela aplicação e não pelo SO. Para isso, deve existir uma biblioteca de rotinas que possibilite à aplicação realizar tarefas como criação/eliminação de threads, troca de mensagens e escalonamento. Vantagens: possibilidade de implementar aplicações multithreads em SOs que não suportam threads. São rápidos por dispensarem acessos ao kernel. Problemas: Tratamento individual de sinais; O SO gerencia cada processo como se existisse apenas um único thread; Em ambientes com múltiplos processadores, não é possível que múltiplos threads de um processo possam ser executados simultaneamente.

19 3.4.1 Threads em Modo Usuário Thread 0 Thread 1 Thread 2 Thread 3 Thread 4 Modo usuário Biblioteca Kernel Modo kernel

20 3.4.2 Threads em Modo Kernel TMK são implementados diretamente pelo núcleo do SO, através de chamadas a rotinas do sistema que oferecem todas as funções de gerenciamento e sincronização. Problema para pacotes em modo kernel é o seu baixo desempenho. Pacotes em modo kernel utilizam chamadas a rotinas do sistema e, consequentemente, várias mudanças no modo de acesso.

21 3.4.2 Threads em Modo Kernel Thread 0 Thread 1 Thread 2 Thread 3 Thread 4 Modo usuário Kernel Modo kernel

22 3.4.3 Threads em Modo Híbrido Combina as vantagens de threads implementados em modo usuário (TMU) e threads em modo kernel (TMK). Um processo pode ter vários TMKs e, por sua vez, um TMK pode ter vários TMUs. O programador desenvolve a aplicação em termos de TMUs e especifica quantos TMKs estão associados ao processo. Os TMUs são mapeados em TMK enquanto o processo está sendo executado. O modo híbrido, apesar da maior flexibilidade, apresenta problemas herdados de ambas as implementações.

23 3.4.3 Threads em Modo Híbrido TMU 0 TMU 1 TMU 2 TMU 3 TMU 4 TMU 5 Modo usuário Biblioteca TMK 0 TMK 1 TMK 2 TMK 3 Kernel Modo kernel

24 3.4.4 Scheduler Activations Os problemas apresentados no pacote de threads em modo híbrido existem devido à falta de comunicação entre os threads em modo usuário e em modo kernel. A estrutura de dados chamada scheduler activations (ativações do agendador) combina o melhor das duas arquiteturas, realizando a troca informações do núcleo do sistema com a biblioteca de threads. O melhor sentido a palavra é planejador, pois temos frequentemente a situação onde vários processos estão prontos para serem executados e este, planeja para a tomada de decisão do sistema operacional de qual processo deve ser executado e este é o scheduler. A maneira de alcançar um melhor desempenho é evitar as mudanças de modos de acesso desnecessárias (usuário-kernel-usuário).

25 3.4.4 Scheduler Activations Thread 0 Thread 1 Thread 2 Thread 3 Thread 4 Modo usuário Biblioteca Kernel Modo kernel

26 3.5 Programação Multithread O conjunto de rotinas disponíveis para que uma aplicação utilize as facilidades dos threads é chamado de pacotes de threads. O desenvolvimento de aplicações multithread exige que a comunicação e o compartilhamento de recursos entre os diversos threads sejam feitos de forma sincronizada. Um fator importante em aplicações multithread é o número total de threads e a forma como são criados e eliminados. Para obter os benefícios do uso de threads, uma aplicação deve permitir que partes do seu código sejam executadas concorrentemente de forma independente.