Parte 06: Introdução a Threads em Sistemas Operacionais

SISTEMAS SISTEMAS OPERACIONAIS OPERACIONAIS SISTEMAS SISTEMAS OPERACIONAIS OPERACIONAIS Parte 06 Threads Professor Eduardo Xavier Parte 06 Threads Professor Eduardo Xavier Introdução Introdução O que é thread Thread é um fluxo de controle que pode ser considerado um processo leve sem recursos associados a ele Histórico A versão tradicional de SO até o final da década de 1970 previa que cada processo tinha seu próprio espaço de endereçamento de memória e um único thread de controle monotarefa Ou seja um único programa tem o contrôle de todo o espaço de endereçamento do processo Mais tarde o conceito de processo passou a permitir que o espaço de endereçamento fosse dividido entre dois ou mais programas multitarefa o que separa o conceito de processo e tarefa um processo pode conter mais de uma tarefa Isso melhora o desenvolvimento de aplicações concorrentes pois a comunicação entre tarefas ocorre dentro do processo Introdução Introdução O desenvolvimento de aplicações em multithread é mais complexo que em monothread A possibilidade de paralelismo traz novos problemas de comunicação e sincronização para serem resolvidos Praticamente todos os sistemas operacionais modernos dão suporte ao processamento multithread atendendo à crescente evolução do hardware e software Multiplos processadores ou núcleos Sistemas clienteservidor Sintemas distribuídos Por Que Usar Threads Por Que Usar Threads Motivo 1 Em muitas aplicações ocorrem várias atividades ao mesmo tempo e algumas dessas atividades podem ser bloqueadas em certos momentos Se o processo for composto de uma tarefa única o bloqueio de uma atividade paralisaria o processo inteiro Se o processo for dividido em diversas tarefas será possível executar uma tarefa enquanto outras estão bloqueadas Além disso o modelo de programação se torna mais simples e pode ser contemplado por execuções quase paralelas Por Que Usar Threads Por Que Usar Threads Motivo 2 Threads são mais fáceis e rápidos de criar e destruir do que processos convencionais o que torna a execução mais rápida Todos os recursos necessários são associados ao processo como um todo e não a um thread apenas Se há muitas tarefas a serem desempenhadas ou se acontecem muitas alternâncias entre essas atividades a opção de gerenciar threads em vez de processos se torna mais atraente Por Que Usar Threads Por Que Usar Threads Motivo 3 O uso de threads não apresenta praticamente nenhuma vantagem em termos de desempenho se todas essas threads são CPUbound muito processamento e pouco IO Entretanto na medida em que crescem as atividades de IO dentro do processo a ideia de se ter tarefas executadas paralelamente uso de CPU acontecendo enquanto outra tarefa realiza IO vai se tornando atraente Por Que Usar Threads Por Que Usar Threads Motivo 4 Sistemas com múltiplas CPUs oferecem a possibilidade paralelismo real É claro que esse paralelismo real pode ser desfrutado por vários processos concorrentes mas é mais eficientemente usado por threads dentro de um mesmo processo pois neste caso não há necessidade de mudanças de contexto Ambientes Monothread Ambientes Monothread Nesta abordagem todas as instruções desvios funções e subrotinas estão contidas em um único programa que ocupa o espaço de endereçamento do processo Aplicações concorrentes são implementadas apenas usando múltiplos processos independentes ou subprocessos Isso consome mais recursos do sistema para administrar vários processos mudanças de contexto gerenciamento de memória comunicação etc Cada processo tem seu próprio contexto de hardware contexto de software e espaço de endereçamento Ambientes Multithread Ambientes Multithread Nessa abordagem um único processo pode hospedar dentro de si mais de um programa que compartilham alguns recursos deste processo Cada thread é uma tarefa sub rotina que deve ser definida pelo programador do processo bem como a forma de execução que o processo vai adotar Threads dentro de um mesmo processo compartilham o espaço de endereçamento e o contexto de software porém possuem contextos de hardware diferentes Ambientes Multithread Ambientes Multithread Threads compartilham o processador da mesma maneira que os processos e podem sofrer as mesmas mudanças de estado Em um ambiente multithread os recursos são alocados para o processo e compartilhados pelos threads mas o escalonamento é feito por thread e não pelo processo Ou seja o sistema não seleciona um processo para controlar o processador e sim um de seus threads Arquitetura e Implementação Arquitetura e Implementação O conjunto de rotinas disponíveis para que uma aplicação utilize as facilidades dos threads é chamado de pacote de threads Existem diferentes abordagens de implementação deste pacote em cada sistema operacional Cada uma tem um impacto diferente em desempenho concorrência e modularidade das aplicações Threads podem ser oferecidas de quatro formas Modo Usuário Modo Kernel Modo Híbrido Scheduler Activation Arquitetura e Implementação Arquitetura e Implementação TMU Threads em Modo Usuário Os threads são implementados pela aplicação e não pelo sistema operacional que desconhece a existência dos mesmos Toda o gerenciamento fica a cargo da aplicação que deve utilizar bibliotecas contendo rotinas capazes de criar destruir e trocar mensagens entre threads A grande vantagem dessa abordagem é que é possível implementar threads mesmo que o SO não seja projetado para suportálas pois uma vez que o controle do processador seja passado ao processo o mesmo pode implementar suas threads Isso permite inclusive que o processo implemente um escalonamento diferente daquele adotado pelo SO para seus próprios threads dentro de certas limitações é claro TMUs são rápidos e eficientes porque dispensam acesso ao kernel do SO evitando mudanças do modo de acesso usuáriokernel usuário Arquitetura e Implementação Arquitetura e Implementação TMU Threads em Modo Usuário continuação Um problema é que como o SO não vê threads o mesmo considera que o processo todo é um único thread No momento em que um thread do processo aciona uma rotina que o coloca em estado de espera rotina bloqueante todo o processo é bloqueado A solução é substituir as rotinas bloqueantes por rotinas não bloqueantes que paralisem apenas um thread e passe o controle para outro thread do processo Isso acontece sem conhecimento do usuário ou do SO Outro problema é que o SO envia sinais para o processo como um todo e ele é que deve identificar e tratar para que thread o sinal deve chegar Há também problemas no escalonamento Em ambientes com múltiplas CPUs não é possível distribuir os threads pelas mesmas pois o SO só enxerga o processo como uma única unidade indivisível Isso limita drasticamente o grau de paralelismo possível para cada processo Arquitetura e Implementação Arquitetura e Implementação TMK Threads em Modo Kernel ou Threads em Modo Núcleo Os threads são implementados pelo núcleo do sistema operacional que oferece rotinas de controle para gerenciamento e sincronização O SO sabe da existência de cada thread e é capaz de realizar escalonamento individual entre eles o que permite execução simultânea de threads de um mesmo processo em múltiplas CPUs O grande problema dos TMK é a queda no desempenho causada pelas constantes mudanças de modo de execução usuáriokernel usuário Além disso o processo deve solicitar ao SO cada criação ou destruição de thread o que demanda mais tempo Arquitetura e Implementação Arquitetura e Implementação TMU x TMK Arquitetura e Implementação Arquitetura e Implementação Threads em Modo Híbrido Esta solução combina as vantagens de threads em modo usuário TMU com threads em modo kernel TMK Um processo pode ter vários TMKs Um TMK pode ter vários TMUs O programador desenvolve em função do número de TMUs necessários mas especifica quantos TMKs podem ser usados pelo processo Os TMUs são mapeadosdistribuídos durante a execução pelos TMKs disponíveis O programador pode utilizar apenas TMUs apenas TMKs ou uma combinação de ambos Apesar de ser mais flexível essa solução também herda todos os problemas das soluções originais combinados Arquitetura e Implementação Arquitetura e Implementação Scheduler Activations Esta solução tenta resolver os problemas do modo híbrido Esses problemas em sua maioria são causados pela falta de comunicação entre TMUs e TMKs Em vez de dividir os threads em modo usuário e modo kernel o sistema usa uma estratégia chamada Scheduler Activations onde o núcleo do SO se comunica com os threads por meio de uma biblioteca A biblioteca que executa sempre em modo usuário evita mudanças frequentes do modo de acesso usuáriokernekusuário quando um thread entra em modo de espera Ela aciona outros threads comunicandose com o núcleo do SO que está o tempo todo em modo kernel Assim não acontece mudança de modo de acesso no thread e sim uma conversa entre camadas que já estão executando no modo desejado Modelos de Programação Modelos de Programação Desenvolver aplicações multithread é complexo Exige atenção a detalhes de sincronização e comunicação para evitar inconsistências deadlocks e outros problemas Uma aplicação com excesso de threads pode gerar overhead no sistema causando problemas de desempenho A implementação de threads pode ser Estática quantidade de threads é fixa e definida na criação do processo da aplicação Dinâmica quantidade de threads aumenta ou diminui conforme a demanda da aplicação O uso bem gerenciado de paralelismo mesmo em sistemas com um único processador é bastante vantajoso A abordagem multithread é especialmente interessante quando executa aplicativos com muitas operações de IO e eventos assíncronos Referências Bibliográficas Referências Bibliográficas Arquitetura de Sistemas Operacionais Francis Machado Luiz Maia 4a Edição Capítulo 6 Thread