Notas da Aula 4 - Fundamentos de Sistemas Operacionais

Transcrição

1 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 linha de execução determina qual a sequência de instruções executadas pelo processo. No entanto, um processo pode requisitar ao SO a criação de outras threads. Ao requisitar a criação de uma nova thread, o processo informa qual rotina será executada pela thread. Por exemplo: int main() { x = x+1; create_thread(funcao_1); y = x + 5; return(0); void funcao_1() { k = l + 1;... Nos trechos de código acima, o processo inicialmente criado tem uma única thread que executa a sequência de instruções da função main(). Em um dado ponto desta execução, o processo faz uma chamada de sistema (neste exemplo, denominada create_thread()) que requisita ao SO a criação de uma nova thread. A nova thread, por sua vez, deve executar a função denominada funcao_1(). A partir deste momento, o processo passa a contar com duas threads simultâneas. Ou seja, uma linha de execução que continua executando as instruções da função main() e outra que passa a executar a sequência de instruções da função funcao_1(). Um efeito similar pode ser alcançado com o uso da função fork() discutida nas aulas anteriores. Neste caso, o código ficaria: int main() { x = x+1;

2 pid = fork(); if (pid == 0) funcao_1(); y = x + 5; return(0); void funcao_1() { k = l + 1;... Após a chamada da função fork(), o SO cria uma cópia exata do processo original. Ambas prosseguem suas execuções a partir do comando if. No entanto, para o processo recémcriado, pid terá valor 0. Este novo processo terá então sua execução desviada para a função funcao_1(), enquanto o processo original continuará a execução da função main(). Qual, então, é a diferença entre threads e processos? Quando uma nova thread é criada, o SO não precisa criar uma duplicata do espaço de endereçamento do processo. Ao invés disso, a nova thread utiliza o mesmo espaço de endereçamento original. Por outro lado, ao chamar a função fork(), o processo é completamente duplicado: uma nova área na memória física é criada para acomodar o novo processo e toda uma rotina de cópia do estado do processo original é executada. Ao contrário do que acontece com processos diferentes, para os quais um grande número de informações sobre o estado do processo atual precisam ser salvas, no chaveamento entre threads de um mesmo processo apenas alguns poucos registradores precisam ser guardados. Por estas características, as threads são chamadas às vezes de processos leves. Em resumo, uma thread é apenas uma linha de execução de um processo, representada pelo valor de alguns registradores. Uma thread pertence a um processo, enquanto um processo pode ter mais de uma thread. Também é importante notar que todo processo tem ao menos uma thread. Embora threads e processos sejam conceitos bem diferentes, ambos são, muitas vezes, citados como dois mecanismos similares de programação. De fato, do ponto de vista de um programador, a grande diferença entre threads e processos é o fato de que threads de um mesmo processo compartilham memória, enquanto processos distintos têm espaços de endereçamento separados. O compartilhamento de memória entre threads geralmente é visto como uma vantagem, já que simplifica a troca de informação. Para que dois processos distintos se comuniquem, é necessária a adoção de alguma outra solução mais complexa. Por outro lado, o compartilhamento de memória pode tornar a depuração de um programa mais difícil. Isso porque o erro em uma thread, que faz com que ela escreva valores inválidos na

3 memória, pode se manifestar como um sintoma em outra thread, que simplesmente lê valores da memória e efetua algum processamento. 2. Programação Concorrente Dizemos que um programa é concorrente quando ele utiliza diversas linhas de execução simultaneamente. Em outras palavras, um programa concorrente é aquele que utiliza várias threads ou processos para executar a tarefa a qual se propõe. Programas concorrentes podem, inclusive, misturar o uso de threads com processos. Ou seja, o programa pode criar um conjunto de processos os quais, por sua vez, podem disparar várias threads de execução. É tarefa do programador determinar qual combinação de threads e processos faz mais sentido para o programa em questão. Há inúmeros exemplos de programas concorrentes usados comumente. Um exemplo bastante claro é um servidor web. Quando iniciado, o servidor tem, inicialmente, um único processo ou uma única thread que aguarda por conexões. Ao receber uma conexão, o servidor pode criar um novo processo (ou thread) para cuidar do atendimento desta conexão. O processo ou thread principal volta ao estado inicial para esperar por novas conexões. Programas concorrentes também são muitas vezes chamados de programas paralelos, pois eles utilizam várias linhas de execução paralelas no tempo. Programas que utilizam uma única thread ou processo são conhecidos como programas sequenciais. Há algumas razões para a utilização da programação concorrente. Uma delas é o fato de que algumas tarefas são intrinsecamente paralelas. Considere o exemplo do servidor web. Espera-se que um servidor seja capaz de atender a várias requisições simultâneas. Embora seja possível implementar isso em um programa sequencial, é mais intuitivo escrever este programa de maneira paralela. Além disso, programas paralelos podem ser mais eficientes que os sequenciais. Isso ocorre por duas razões: 1. Existência de sistemas multiprocessados: com vários processadores, é possível executar duas ou mais threads ao mesmo tempo. Programas sequenciais, por outro lado, não conseguem tirar proveito disso. 2. Sobreposição de operações de E/S: mesmo em sistemas monoprocessados, quando um processo ou thread de um programa concorrente requisita uma operação de E/S, o tempo ocioso pode ser utilizado por outro processo ou thread do programa. Em um programa sequencial, toda a execução é bloqueada pelo pedido de E/S. Existem, entretanto, desvantagens na programação concorrente. Em primeiro lugar, é preciso haver uma coordenação entre as threads ou processos, o que nem sempre é trivial. Além disso, erros em programas concorrentes são mais difíceis de se depurar, pois é preciso identificar qual thread ou processo causou o problema. Programas concorrentes são também menos intuitivos, pois os programadores em geral tem uma linha de raciocínio linear (sequencial). Isso faz com que o programador faça algumas suposições inválidas, como por exemplo sobre a velocidade de execução dos processos. Por último, a ordem de execução dos

4 processos ou threads de um programa concorrente costuma ser aleatória. Isso dificulta ainda mais a depuração dos programas, pois erros muitas vezes são dependentes da ordem em que os processos são executados. Existem dois tipos diferentes de paralelismo, ligados ao tipo de hardware no qual um programa concorrente é executado. Se um programa concorrente é executado em máquinas multiprocessadas, diz-se que o paralelismo é real. Caso o programa seja executado em uma máquina monoprocessada, diz-se que o paralelismo é aparente. 3. Especificação do Paralelismo As chamadas exatas para criação e manipulação de threads e processos variam de SO para SO. No entanto, existem alguns tipos gerais de representação para programas concorrrentes. Embora os nomes das funções possam ser diferentes em um dado sistema, a estrutura do programa será sempre similar a uma destas representações. No paralelismo explícito, o programador define (explicitamente) em que ponto da execução cada thread ou processo será criado e que tarefa cada um executará. O programador é responsável pela criação, comunicação, sincronização e encerramento de todas as threads e processos. Para isso, são utilizadas três funcionalidades básica: 1. Função create_process(): cria um novo processo (ou thread). 2. Função exit(): encerra um processo ou uma thread. 3. Função wait_process(): o processo que chama esta função, espera que o processo (ou thread) especificado como argumento seja encerrado. No paralelismo implícito, o programador não se preocupa com como criar e gerenciar as threads ou processos. Ao invés disso, ele simplesmente indica no código pontos que devem ser paralelizados. O compilador da linguagem na qual o programa está sendo escrito é responsável por seguir as indicações do programador e criar as threads ou processos necessários. Neste tipo de representação, são utilizados dois comandos básicos: o parbegin e o parend. O parbegin indica o início de um bloco que deve ser paralelizado pelo compilador. O parend indica o final deste bloco. Cada instrução dentro do bloco deve ser executada por uma thread ou processo diferente. Geralmente, os Sistemas Operacionais fornecem suporte apenas à versão explícita de paralelismo, provendo funções similares às três apresentadas. Por este motivo, o paralelismo explícito é mais comum. Algumas linguagens, no entanto, dão suporte ao paralelismo implícito. Um exemplo é a biblioteca OpenMP, disponível para C e C++. Comparativamente, o paralelismo implícito é mais simples, do ponto de vista do programador. Ele não precisa se preocupar com tantos detalhes de gerenciamento de threads e processos. Por outro lado, o paralelismo explícito é mais flexível, dando mais liberdade para o programador gerenciar como achar melhor suas threads e processos.

5 Há ainda uma terceira maneira de representar programas concorrentes. São os chamados grafos de precedência. Nestes grafos, cada vértice representa uma determinada tarefa a ser executada no programa. Um arco saindo de uma tarefa A para outra tarefa B indica que a tarefa B só pode ser iniciada depois que a tarefa A tiver sido concluída. Desta forma, é possível representar facilmente relações de dependência entre tarefas. Algumas plataformas recebem um programa especificado através de um grafo de precedência e ordenam a execução de processos ou threads relativos a cada tarefa de modo a otimizar a execução (e.g., reduzir o tempo total de execução do programa). 4. Compartilhamento de Recursos Geralmente, processos ou threads de um programa concorrente compartilham recursos. Há vários tipos de recursos que podem ser compartilhados. Alguns exemplos são: variáveis, sockets e arquivos. Muitas vezes, estes recursos são usados como um meio de comunicação entre os processos ou threads do programa concorrente. O recurso compartilhado mais comum é, possivelmente, a memória. Threads de um mesmo processo compartilham todo o espaço de endereçamento, então qualquer variável de um programa concorrente acessada por várias threads é compartilhada. Mesmo processos separados podem compartilhar memória, através de chamadas de sistema. Tais chamadas pedem ao SO que aloque uma área de memória física que pode ser acessada por um conjunto de processos. Ter uma variável compartilhada pode servir como um mecanismo de comunicação entre processos ou threads. Por exemplo, duas threads podem compartilhar uma variável inicio_thread_1, inicialmente com valor 0. Quando a thread 1 começa sua execução, ela pode alterar o valor da variável para 1. Desta forma, com um simples teste do valor da variável inicio_thread_1, a thread 2 sabe se a outra thread foi iniciada ou não. Um exemplo clássico de aplicação de programação concorrente com compartilhamento de memória é o problema do Produtor-Consumidor. Neste tipo de aplicação, existem vários processos (ou threads) que atuam como produtores de dados. Por exemplo, as threads produtoras podem realizar um determinado cálculo que resulta em um dado a ser impresso. Há também um ou mais processos (ou threads) que atuam como consumidores. Ou seja, eles recebem os dados produzidos e realizam algum tipo de operação sobre eles (por exemplo, imprimi-los na tela). Os produtores e os consumidores compartilham uma área de memória na qual os dados são colocados e posteriormente retirados. Um sistema comum que funciona desta forma são os servidores de impressão. Vários programas podem requisitar que determinados dados (arquivos) sejam impressos. Estes processos são os produtores. Ao invés de cada processo tentar enviar diretamente seus dados para a impressora, eles colocam os dados em uma área de memória compartilhada, chamada de spool de impressão. Um processo especializado lê os dados do spool e faz a comunicação com a impressora para realizar a impressão propriamente dita.

6 Em geral, a área de memória compartilhada é um buffer circular. Este buffer tem posições de memória para acomodar os dados produzidos, além de dois ponteiros. Um deles aponta para a primeira posição ocupada do buffer, enquanto o outro aponta para a primeira posição livre. Ao adicionar um novo elemento ao buffer, o produtor insere seu dado na primeira posição livre e avança o ponteiro. Ao remover um dado do buffer, o consumidor lê a primeira posição ocupada e avança o ponteiro. Obviamente, cuidados têm que ser tomados para que não haja overflow ou underflow do buffer. Ou seja, para que produtores não insiram novos dados se não há posições livres e para que os consumidores não tentem ler dados se não houver dados a serem lidos. 5. Região Crítica Uma região (ou seção) crítica é um trecho de programa no qual ocorre a manipulação de algum recurso compartilhado. É importante notar que um mesmo programa pode ter várias regiões críticas. A relevância das seções críticas está no fato de que a manipulação simultânea de recursos compartilhados entre dois ou mais processos pode resultar em erros em um programa concorrente. Para exemplificar este tipo de erro, suponha que duas threads compartilham uma variável x, inicialmente com o valor 0. Suponha ainda que, em determinado momento, ambas as threads tentam incrementar x. O resultado esperado da execução das duas threads é que x tenha o valor 2. Entretanto, dependendo da ordem de execução das threads isso pode não ser verdade. O problema acontece porque o incremento de uma variável geralmente é traduzido para um conjunto de instruções de máquina. Por exemplo: MOV acc, x ; Move o valor da variável x para o acumulador INC acc ; Incrementa o valor do acumulador. MOV x, acc ; Move o valor do acumulador para x Suponha que a primeira thread execute a primeira instrução e seja interrompida (por exemplo, pelo fim do seu slice de tempo atual). Neste instante, a segunda thread começa a ser executada e executa todas as três instruções. O valor da variável x, portanto, passa a ser 1. Quando a primeira thread volta à execução, o valor do registrador acumulador está em 0, pois este foi o resultado da execução da primeira instrução (executada antes da segunda thread alterar o valor de x). A primeira thread executa as duas últimas instruções, fazendo com que x continue com o valor 1. Os trechos de código nos quais as duas threads fazem suas manipulações da variável x são as regiões críticas do código (em relação a x; podem existir outras, relacionadas a outros recursos). A ordem em que as threads são colocadas ou retiradas do processador durante o processamento da região crítica pode afetar o resultado da computação.

7 O problema do Produtor-Consumidor também contém uma região crítica. Como o buffer circular (junto com seus ponteiros) é um recurso compartilhado, a ordem de execução dos processos no momento de inserção ou remoção de elementos do buffer pode causar erros. Suponha, por exemplo, que um produtor P1 insira um dado D1 na próxima posição livre do buffer. No entanto, imediatamente antes de atualizar o ponteiro da próxima posição livre, P1 é interrompido e P2 entra em seu lugar. Suponha ainda que P2 decida inserir um dado D2 no buffer. Como o ponteiro não foi ainda atualizado por P1, P2 irá sobrescrever o dado D1. Esta situação, em que a ordem de execução dos processos ou threads na região crítica pode causar erros na computação, é chamada de Condição de Corrida. Programas sujeitos a condições de corrida podem ter resultados inesperados e variáveis, e sua depuração é, em geral, muito complicada. Existem duas maneiras de solucionar o problema da condição de corrida. A primeira é chamada de Exclusão Mútua e consiste em impedir que mais de um processo acesse a região crítica simultaneamente. Neste caso, a condição de corrida não ocorrerá, pois o estado do recurso compartilhado não poderá mudar ao longo da execução da região crítica por um processo (ou thread). Outra possível solução é chamada de Operação Atômica e consiste em tornar atômico o processamento realizado na região crítica. Uma operação atômica é aquela que não pode ser divisível no tempo, ou seja, não pode sofrer interrupções. Logo, dada esta condição, condições de corrida também são impossíveis.