Universidade Federal do Tocantins.
 Em espera (processo esperando
Arraias, 04/06/2020.
Aluna: Gabrielle Azevedo.
Professor: Wosley Arruda.
Disciplina: Sistemas Operacionais.
Gerência de Processos
Processos
É um programa em execução.
Um sistema é composto por um
conjunto de processos do Sistema
Operacional executando códigos tanto para
o sistema quanto para os usuários.
Processos podem ser executados de
forma concorrente com a CPU (ou CPUs)
multiplexada alternando entre eles,
possibilitando que o SO torne o computador
mais produtivo.
Antigamente, usava-se os termos jobs,
mas processo os substituiu.
O processo
O processo é mais que o código do
programa, incluindo a atividade corrente,
representada pelo contador do programa e
o conteúdo dos registradores do processador,
e incluindo ainda a pilha do processo, que
contém os dados temporários, e uma seção
de dados, que contém variáveis globais.
Pode incluir ainda um heap (memória
dinamicamente alocada durante o tempo
de execução do processo).
O processo é uma entidade ativa, com
um contador de programa especificando
qual será a próxima instrução e o conjunto de
recursos associados.
Mesmo que dois processos estejam
associados ao mesmo programa, ainda são
considerados sequências de execução
separadas.
É comum que um processo gere muitos
outros processos ao ser executado.
Estado do Processo
Sempre que um processo é executado,
seu estado muda. Esse estado é definido, em
parte, pela atividade corrente do processo,
que pode ser:
 Novo
 Em execução
que algum evento ocorra);
 Pronto (esperando para ser
atribuído a um processador;
 Concluído;
Esses nomes variam entre SOs.
Apenas um processo pode ser
executado em um processador por vez,
embora muitos processos possam estar em
espera ou prontos.
Bloco de Controle de Processo
Cada processo é representado no SO
por um bloco de controle de processo (PCB)
– também chamado de bloco de controle de
tarefa.
O PCB contém muitas informações
associadas a um processo específico,
incluindo:
 Estado do processo;
 Contador do programa (indica a
próxima instrução a ser executada)
 Registradores da CPU (devem ter
suas informações salvas, junto com
o contador do programa, para ser
retomado, mesmo que haja uma
interrupção.
 Informações de scheduling
(incluem a prioridade de um
processo, ponteiros para filas de
scheduling e outros parâmetros de
scheduling)
 Informações do gerenciamento de
memória
 Informações de status de I/O
(incluem lista de dispositivos de I/O
alocados ao processo, lista de
arquivos abertos etc.)
Um PCB é simplesmente o repositório
de todas as informações que possam variar
entre os processos.
Threads
A maioria dos SOs atualmente permite
que um processo tenha múltiplos threads de
execução, desempenhando mais de uma
atividade por vez.
Em sistemas que suportam threads, o
PCB é expandido para incluir as informações
de cada thread.

Scheduling Processos
O objetivo da multiprogramação é
que sempre haja processos em execução
para maximizar o uso da CPU. Já o objetivo
do compartilhamento de tempo é alternara a
CPU entre os processos tantas vezes, que os
usuários possam interagir com cada
programa enquanto ele está sendo
executado. Para alcançar esses objetivos, o
scheduler de processos seleciona um
processo disponível (ou processos disponíveis)
para execução na CPU.
Filas de Scheduling
Os processos que entram no sistema
ficam em uma fila de jobs, que contém todos
os processos do sistema.
Os processo da memória principal que
estão prontos para execução, ficam em uma
fila de prontos.
O cabeçalho de uma fila de prontos
contém ponteiros para o 1º e o último PCBs da
lista. Cada PCB inclui um ponteiro para o
próximo PCB da lista.
O pai de um processo é o processo que
o criou e seus filhos, são quaisquer processos
que ele tenha criado. Seus irmãos são
processos que tenham o mesmo pai.
Quando a CPU é alocada para um
processo, ele é executado por um tempo até
ser interrompido ou colocado em espera pela
ocorrência de algum evento específico.
A lista de processos em espera por um
dispositivo de I/O é chamada de fila do
dispositivo e cada dispositivo tem sua fila
própria.
Primeiro, um processo é colocado na
fila de prontos e fica lá até ser selecionado
para ser executado (despachado). Quando
a CPU é alocada ao processo e este entra em
execução, vários eventos podem ocorrer:
 O processo faz uma solicitação de
I/O, sendo, então, inserido em uma
fila de I/O.
 O processo cria um processo-filho e
espera que ele termine.
 O processo é removido à força da
CPU por causa de uma interrupção
e deve ser devolvido à fila de
prontos.
Um processo fica nesse ciclo até ser
finalizado – quando é removido de todas as
filas.
Schedulers
Um processo passa por várias filas de
Scheduling durante sua vida e o SO deve
selecionar processos nessa fila de alguma
forma. O processo de seleção é feito pelo
schedule apropriado.
Muitas vezes, em um sistema batch
mais processos são submetidos do que é
possível executar, por isso, eles são
armazenados em uma memória de massa,
aonde fica até a execução posteriormente.
Scheduler de longo prazo (ou
scheduler de jobs), selecionas processos
nesse pool e o carrega na memória para
execução.
O scheduler de curto prazo (ou
scheduler da CPU seleciona os processo
prontos e aloca a CPU para um deles.
A diferença entre esses dois scheduler
está na frequência de execução: o de curto
prazo é executado ao menos uma vez a
cada 100 milissegundos, enquanto o de longo
prazo é executado com muito menos
frequência.
O de longo prazo controla ainda o
grau de multiprogramação. Ele pode ser
invocado apenas quando um processo deixa
o sistema.
A maioria dos processos são ou
limitados por I/O (gasta mais tempo fazendo
I/O do que executando computação) ou
limitados por CPU (Executa mais computação
do que solicita I/O). Um sistema terá melhor
desempenho ao combinar os dois.
Em alguns sistemas, o scheduler de
longo prazo pode ser ausente ou mínimo.
Alguns sistemas, incluem um scheduler
intermediário – às vezes pode ser vantajoso
remover um processo da memória, reduzindo
o grau de multiprogramação e, depois, este
processo pode ser reintroduzido na memória
(esse processo é chamado de swapping).
O swapping pode retirar sobrecargas
ou melhorar o mix de processos.
Mudança de Contexto
Uma mudança de contexto ocorre
quando um processo é interrompido e o seu
estado precisa ser salvo (salvamento de
estado) – salvo no PCB pelo kernel – para
depois ser retomado (restauração do
estado).
O tempo gasto na mudança de
contexto é puro overhead, já que o sistema
não executa trabalho útil durante a troca de
processos.
Multitarefa em Sistemas Móveis
IOS 4 dá suporte à multitarefa
(processo é executado em background se ser
suspenso), ficando disponível apenas para
um número limitado de aplicações que:
 Executam uma única tarefa de
tamanho finito.
 Recebem notificações sobre a
ocorrência de um evento.
 Têm tarefas de background de
longa execução.
Android não tem essas restrições de
tipos de aplicações. Se uma aplicação
precisa ser processada em background, ela
usa um serviço (componente separado da
aplicação que é executado em nome do
processo de background).
Operações sobre Processos
Como os processos são muito
dinâmicos, na maioria dos sistemas, os
sistemas devem fornecer mecanismo para
criação e encerramento de processos.
Criação de Processos
Durante sua execução, um processo
pode criar vários processos novos.
A maioria dos SOs identifica os
processos de acordo com um identificador
de processo (PID) exclusivo
normalmente, é um número inteiro. O PID
pode ser usado ainda como um índice de
acesso a vários atributos de um processo
dentro do kernel.
Quando um processo cria um
processo-filho, este precisa de recursos, para
executar a sua tarefa, que podem ser obtidos
através do SO ou pode ficar restrito a um
subconjunto dos recursos do processo-pai
(neste caso, o processo-filho é impedido de
sobrecarregar o sistema).
O pai pode dividir seus recursos entre os
seus filhos ou pode compartilhar alguns
recursos (como memória e arquivos) com
vários deles.
Além de fornecer diversos recursos
físicos e lógicos, o processo-pai pode passar,
na inicialização, dados (entradas) ao
processo-filho.
Quando um processo cria um novo
processo, há duas possibilidade de
execução:
 O pai continua a ser executado
junto com seus filhos.
 O pai espera até que alguns de
seus filhos ou todos eles sejam
encerrados.
Duas possibilidades de
endereçamento para o novo processo:
 O processo-filho é uma duplicata
do processo-pai.
 O processo-filho tem um novo
programa carregado nele.
Encerramento de Processos
Um processo se encerra quando a
execução do seu último comando é
finalizado e ele solicita a própria exclusão ao
SO.
Um processo pode causar o
encerramento de outro através de uma
chamada de sistema apropriada –
usualmente, apenas o pai pode fazer isso.
O pai precisa saber as identidades de
seus filhos para encerrá-los.
O pai pode encerrar o seu filho por
várias razões:
 O filho excedeu o uso de algum dos
recursos que recebeu.
 A tarefa atribuída ao filho não é
mais necessária.
 O pai está sendo encerrado e o SO
só pode fazer isso após encerrar
seus filhos.
que, Alguns sistemas não permitem que seu
filho exista se o seu pai for encerrado. O
encerramento dos filhos para chegar ao do
pai é chamado de encerramento em
cascata e geralmente é iniciado pelo SO.
Um processo que foi encerrado, mas
seu pai ainda não chamou o wait() – que
permite que o pai saiba o status do filho – é
chamado de processo zumbi.
Se um pai não chamasse o wait() e
fosse encerrado, deixando seus filhos, estes se
tornariam órfãos.
Comunicação Interprocessos
Os processos executados
concorrentemente podem ser
independentes (que não compartilham
dados entre si) ou cooperativos (quando
pode ser afetado ou afetar outros processos).
Arquitetura Multiprocessos – Navegador
Chrome
As vezes um navegador pode cair. Isso
não é um problema quando ele exibe
problemas de apenas um website, mas, a
maioria dos navegadores atuais fornecem
navegação em guias, o que torna sua queda
um problema, já que todo o processo,
inclusive as outras guias, também cairá.
O Chrome resolve esse problema
usando uma arquitetura Multiprocessos. Ele
identifica três tipos de processos:
 Navegador: gerencia a interface
do usuário e o I/O de disco e de
rede. Criado apenas uma vez,
quando o Chrome é iniciado.
 Renderizadores: Contêm a lógica
para renderização de páginas
web. É criado para cada website
aberto em uma guia.
 Plugin: Criado para cada tipo de
plugin (como Flash) em uso.
Vantagens da abordagem
multiprocesso:
 Websites são executados
isoladamente e, se um cai, ele não
afeta os outros.
 processos renderizadores são
executados em uma sendbox, logo,
o acesso ao I/O de disco e rede é
limitado, minimizando efeitos
invasões na segurança.
 Aumento da velocidade de
computação (apenas para
computadores com vários núcleos
de processamento).
 Modularidade, ao dividir suas
funções em processos ou threads
separados.
 Conveniência, já que um usuário
pode trabalhar em muitas tarefas
ao mesmo tempo.
Processos cooperativos demandam
um mecanismo para comunicação entre
processos (IPC), para troca de dados e
informações. Há dois modelos básicos de
IPCs: memória compartilhada (uma região da
memória é compartilhada, permitindo que
eles troquem informações lendo e gravando
dados na região compartilhada) e Nele, as mensagens enviados por um
transmissão de mensagens (a comunicação
ocorre por meio de mensagens trocadas
entre os sistemas cooperativos).
Os dois modelos são muito comuns e
muitos SOs implementam ambos.
A transmissão de mensagens é útil para
troca de pequenas quantidades de dados e
mais fácil de implementar em um sistema
distribuído. Melhor também para sistemas
com vários núcleos de processamento.
A memória compartilhada, no entanto,
pode ser mais rápida.
Sistemas de Memória Compartilhada
Normalmente, a região de memória
compartilhada reside no espaço de
endereçamento do processo que cria o
segmento de memória compartilhada.
Processos que queiram usar esse segmento,
devem anexá-lo ao seu espaço de
endereçamento, já que o SO tenta impedir
que um processo acesse a memória do outro
processo, por isso, a memória compartilhada
requer que dois ou mais processos
concordem em eliminar essa restrição.
A forma dos dados e a locação são
determinadas pelos próprios processos, pois
eles não ficam sob controle do SO. Eles ainda
são responsáveis por garantir que eles não
estão fazendo gravações na mesma locação
simultaneamente.
Um paradigma comum dos processos
cooperativos é o problema do produtor
consumidor. Um processo produtor é aquele
que produz informações para serem
consumidas por um processo consumidor.
Para permitir que os processos
produtores e consumidores sejam executados
concorrentemente, o produtor e o
consumidor devem estar sincronizados para
que o consumidor não tente consumir um
item que ainda não foi produzido.
Para isso, dois tipo de buffer podem ser
usados: o ilimitado (sem tamanho prático em
seu tamanho), em que o consumidor pode ter
que esperar por novos itens, mas o produtor
sempre pode produzir novos itens, e o buffer
limitado (com tamanho fixo) em que o
consumidor deve esperar se o buffer estiver
vazio, e o produtor deve esperar se ele estiver
cheio.
Sistemas de Transmissão de Mensagens
processo podem ser de tamanho fixo ou
variável.
 Os métodos para implementar
logicamente um link e as operações send()/
receive():
 Comunicação direta ou indireta
 Comunicação síncrona ou
assíncrona
 Armazenamento em buffer
automático ou explícito.
Na comunicação direta, cada
processo que se comunicar deve nomear
explicitamente o receptor ou o emissor da
comunicação.
Há simetria no endereçamento
quando tanto o processo emissor quanto
receptor devem nomear um ao outro para se
comunicar. Uma variante emprega a
assimetria no endereçamento, em que o
receptor não precisa nomear o emissor.
A desvantagem do simétrico e do
assimétrico é a modularidade limitada das
definições dos processos resultantes.
Na comunicação indireta, as
mensagens são enviadas para e
recebidas de caixas postais, ou portas.
Abstratamente, uma caixa postal é um
objeto no qual a mensagem pode ser inserida
por processo e do qual mensagens podem ser
removidas. Cada caixa postal tem uma
identificação exclusiva.
Uma caixa postal pode ser
propriedade de um processo ou do SO. Se
ela é propriedade do processo, faz-se a
distinção entre o proprietário (que só pode
receber mensagem por essa caixa postal) e o
usuário (que só envia mensagem para a
caixa postal).
Uma caixa postal que é propriedade
do SO tem existência própria e não está
associada a nenhum processo específico.
Logo, é o SO que deve:
 Criar uma nova caixa postal
 Enviar e receber mensagens pela
caixa postal
 Excluir uma caixa postal.
A transmissão de mensagens pode ser
com bloqueio (síncrona) ou sem bloqueio
(assíncrona).
Envio com bloqueio: o processo emissor
é bloqueado até que a mensagem seja
recebida pelo receptor ou pela caixa postal.
Envio sem bloqueio: o emissor envia a
mensagem e retoma a operação.
Recebimento com bloqueio: O enviada. Normalmente, o thread emissor
receptor é bloqueado até que a mensagem
fique disponível.
Recebimento sem bloqueio: O
receptor recupera uma mensagem válida ou
nula.
Independentemente de a
comunicação ser direta ou indireta, as
mensagens trocados por processos em
comunicação residem em uma fila
temporária. Essas filas podem ser
implementadas de três maneiras:
 Capacidade zero (ou sistemas de
armazenamento sem
armazenamento em buffer): Fila
tem tamanho máximo de zero,
logo, o link não pode ter
mensagens em espera.
 Capacidade limitada: fila de
tamanho finito em que no máximo
n mensagens podem residir nela.
 Capacidade ilimitada: número de
mensagens potencialmente infinito,
podendo conter várias mensagens
em espera.
Tanto o de capacidade limitada como
ilimitada são conhecidas como sistemas com
armazenamento em buffer automático.
Exemplos de Sistemas IPC
Memória compartilhada POSIX:
organiza a memória compartilhada com o
uso de arquivos mapeados para a memória,
que associam a região da memoria
compartilhada a um arquivo.
Mach – Com transmissão de
mensagens: A maior parte da comunicação
(incluindo todas as informações entre tarefas)
é executada por mensagens, que são
enviadas e recebidas em caixas postais
(chamadas portas no Mach). Ele garante que
várias mensagens do mesmo emissor sejam
enfileiradas na ordem FIFO (primeiro a entrar,
primeiro a sair), mas não garante ordem
absoluta.
As mensagens propriamente ditas são
compostas por um cabeçalho de tamanho
fixo, seguido por uma parte de dados de
tamanho variável. O cabeçalho indica o
tamanho da mensagem e inclui dois nomes
de caixa postal em que, um especifica a
caixa posta para a qual a mensagem será
espera uma resposta, passando assim o nome
da caixa postal do emissor à tarefa receptora,
que a usará como endereço de retorno.
 A parte variável da mensagem é uma
lista de dados tipificados. Cada entrada da
lista tem um tipo, valor e tamanho.
As operações de envio e recebimento
são flexíveis.
Quando a caixa postal está cheia, o
thread emissor tem quatro opções:
 Esperar até haver espaço na caixa
postal.
 Esperar no máximo n milissegundos.
 Não esperar e retornar
imediatamente.
 Armazenar a mensagem,
temporiamente, em cache.
Quando a mensagem puder ser
inserida na caixa postal, outra mensagem
será retornada ao emissor.
A operação de recebimento deve ser
especificada a caixa postal ou o conjunto de
caixas postais (coleção de caixas postais que
podem ser agrupadas e tratadas como uma
única caixa postal) a partir das quais uma
mensagem deve ser recebida.
Os threads de uma tarefa podem
receber mensagens somente de uma caixa
postal ou conjunto de caixas postais para as
quais a tarefa tenha acesso de recebimento.
Se nenhum mensagem está em espera
para ser recebida, o thread pode esperar um
tempo limitado ou não esperar.
O sistema Mach foi projetado para
sistemas distribuídos, mas se mostrou útil
também para sistemas com menos núcleos
de processamento.
O principal problema dos sistemas de
mensagens é o fraco desempenho, causado
pela cópia dupla da mensagem.
Windows: Emprega a modularidade
para aumentar a funcionalidade e reduzir o
tempo necessário à implementação de
novos recursos.
O sistema de mensagens do Windows
é denominado chamada de procedimento
local avançado (ALPC) e é usado na
comunicação entre dois processo na mesma
máquina.
Também usa objetos para estabelecer
e manter uma conexão entre dois processos.
Usa dois tipos de portas: portas de
conexão e portas de comunicação.
Os processo de servidor publicam
objetos portas de conexão que podem ser
vistos por todos os processos.
Quando um cliente requer os serviços
de algum subsistema, ele abre um
manipulador para o objeto porta de conexão
do servidor e envia uma solicitação de
conexão a essa porta. O servidor cria um
canal e retorna um manipulador para o
cliente.
O canal tem um par de portas de
comunicações privadas: um para mensagens
cliente-servidor, outro para mensagens
servidor-cliente. Os canais de comunicação
dão suporte ainda a um mecanismo de
retorno de chamada que permite que o
cliente e o servidor aceitem solicitações
quando estariam esperando uma resposta.
Quando um canal ALPC é criado, há
três técnicas possíveis de mensagens a ser
selecionadas:
 Para mensagens pequenas (até 256
bytes) a fila de mensagens da porta
e usada como repositório
intermediário, e as mensagens são
copiadas de um processo para o
outro.
 Mensagens maiores devem ser
passadas por um objeto seção
(região de memória compartilhada
associada ao canal.
 Quando o volume é grande
demais, existe uma API disponível
que permite que processos de
servidor leiam e gravem
diretamente no espaço de
endereçamento de um cliente.
Comunicação em Sistemas
ClienteServidor
A memória compartilhada e
transmissão de mensagens também podem
ser usadas para comunicação em sistemas
clienteservidor, mas há ainda outras três
estratégias: sockets, chamadas de
procedimento remotas (RPCs) e pipes.
Sockets
Uma extremidade de comunicação.
Um par de processos que estão se
comunicando através de uma rede emprega
um par de sockets – um para cada processo.
Um socket é identificado por um
endereço IP concatenado com um número
de porta e geralmente usam uma arquitetura
clienteservidor, em que o servidor espera
solicitações recebidas de clientes ouvindo
uma porta específica.
 Uma vez que a solicitação é recebida, stub localiza a porta no servidor e organiza os
o servidor aceita uma conexão vinda do parâmetros.
socket do cliente para completá-la. O stub envia, então, uma mensagem
Servidores que implementam serviços par ao servidor usando transmissão de
específicos (FTP, HTTP etc.) ouvem em portas mensagens. Um stub semelhante no lado do
bem conhecidas (abaixo de 1024). servidor recebe essa mensagem e invoca o
Quando um processo cliente inicia a procedimento no servidor. Se necessário,
solicitação de uma conexão, uma porta é valores de retorno são devolvidos ao cliente
atribuída a ele pelo computador hospedeiro. com o uso da mesma técnica.
Os pacotes que viajarem entre os Uma questão a ser tratada é a
hospedeiros serão liberados para o processo diferença de representação de dados nas
apropriado com base no número da porta de máquinas do cliente e do servidor. Para
destino. resolver isso, muitos RPCs definem uma
Todas as conexões devem ser representação de dados independente da
exclusivas. máquina, sendo conhecida como
A linguagem Java tem três tipos de representação de dados externa (XDR). No
sockets diferentes: sockets orientados à lado do cliente, pega os dados e faz a
conexão (TCP), sockets sem conexão (UDP) e conversão XDR e no lado do servidor pega o
socket multicast (que permite que os dados XDR e converte para a máquina do servidor.
sejam enviados a vários receptores). As PRCs podem falhar ou ser
Mesmo que a comunicação com duplicadas e executas mais de uma vez por
sockets seja comum e eficiente, é erros de rede. Para resolver isso, o SO pode
considerada de baixo nível entre os processo assegurar que as mensagens sejam
distribuídos. Um dos motivos é que eles manipuladas exatamente uma vez, no lugar
permitem que somente um fluxo não de no máximo uma vez.
estruturado de bytes seja trocado entre os O esquema RPC requer uma
threads que estão se comunicando. associação entre a porta do cliente e do
servidor. Para os clientes saberem o número
Chamadas de Procedimento Remotas (RPC) da porta do servidor, há duas abordagens
comuns. Na primeira, as informações da
Foi projetada como uma forma de associação são predeterminadas, com
abstrair o mecanismo de chamada de endereços de porta fixos. Na segunda, a
procedimento para uso entre sistemas com associação é obtida de forma dinâmica por
comunicação de rede. um mecanismo de ponto de encontro
As mensagens trocadas na RPC são (também chamado de matchmaker).
bem estruturadas, não sendo apenas O RPX é útil em sistemas distribuídos.
pacotes de dados. Cada mensagem é
endereçada a um daemon RPC, escutando Pipes
em uma porta do sistema remoto, e contém
um identificador especificando a função a Um pipe atua como canal que permite
ser executada e os parâmetros a serem que dois processos se comuniquem.
passados para a função. Essa função é Fornecem uma das maneiras mais simples de
executada, como solicitado, e qualquer comunicação de processos, embora haja
saída é retornada ao solicitante em uma limitações.
mensagem separada. Dois tipos comuns de pipes:
Uma porta é um número incluído no  Pipes comuns: permitem que dois
início de um pacote de mensagem. Quando processos se comuniquem na
um processo remoto precisa de um serviço, forma produtor-consumidor: o
ele endereça a mensagem à porta produtor grava em uma
apropriada. extremidade do pipe (a
O RPC oculta os detalhes que extremidade de gravação) e o
permitem ocorrência da comunicação, consumidor lê da outra
fornecendo um stub no lado do cliente. extremidade (extremidade de
Quando o cliente invoca um procedimento leitura). São unidirecionais
remoto, o sistema RPC chama o stub (comunicação apenas em uma
apropriado, passando os parâmetros direção). Se for necessário
fornecidos ao procedimento remoto. Esse comunicação bidirecional, dois
 pipes devem ser usados, enviando
informações em direções opostas.
Ele não pode ser acessado de fora
do processo que o criou.
Geralmente o pai cria um pipe para
se comunicar com o filho.
 Pipes nomeados: A comunicação
pode ser bidirecional, e nenhum
relacionamento pai-filho é Quando há múltiplos chips de
necessário. Uma vez que um pipe é
estabelecido, vários processos
podem usá-lo.
Threads – Visão Geral
Uma thread é a unidade básica de
utilização da CPU, composto por: um ID de
thread, contador de programa, conjunto de
registradores e uma pilha.
Um thread compartilha sua seção de
código, a seção de dados e outros recursos
so sistema com outros threads pertencentes
ao mesmo processo.
Um processo tradicional tem apenas
um thread de controle, mas se ele tem mais
threads, ele pode executar mais de uma
tarefa ao mesmo tempo.
Motivação
A maioria das aplicações de software
atuais usam mais de um thread (multithreads).
Uma aplicação é geralmente implementada
como um processo separado com diversos
threads de controle.
O método de criação de processos era
comum antes dos threads, mas foram
substituídos, pois a criação de processos é
mais demorada e usa mais recursos.
Os threads têm grande importância
em sistemas com chamadas de
procedimentos remotas (RPCs).
Quando o servidor recebe uma
mensagem, ele a atende usando um thread
separado, permitindo que ele atenda a várias
solicitações ao mesmo tempo.
Benefícios
 Capacidade de resposta
aumentada para o usuário.
 Compartilhamento de recursos
(através de técnicas como
memória compartilhada ou
transmissão de mensagens).
 Economia.
 Escalabilidade (principalmente em
arquiteturas com
multiprocessadores).
Programação Multicore
computação no mesmo chip, cada núcleo é
visto como um processador separado para o
SO. A isso, dá-se do nome de multicore ou
multiprocessadores.
threads
O uso da programação com múltiplos
melhora o eficiência dos
multiprocessadores e aumenta a
concorrência.
Os threads podem ser executados em
paralelo, já que cada núcleo pode executar
um thread.
Diferença entre paralelismo e
concorrência: O sistema é paralelo quando
pode executar mais de uma tarefa ao mesmo
tempo. Já a concorrência, é quando um
sistema consegue ir trocando entre várias
tarefas de forma que elas progridam.
Desafios da Programação
Cinco áreas apresentam desafios para
a programação de sistemas multicore:
 Identificação de tarefas que
possam ser divididas em tarefas
separas e concorrentes.
 Equilíbrio, por parte dos
programadores, para assegurar
que as tarefas desenvolvam
esforço igual ou de mesmo valor.
 Divisão de dados para execução
em núcleos separados.
 Dependência de dados. Os dados
acessados pelas tarefas devem ser
examinados para determinar
dependências entre duas ou mais
tarefas.
 Teste e depuração. Quando um
programa está sendo executado
em paralelo em múltiplos núcleos,
podem existir caminhos de
execução diferentes.
Tipos de Paralelismo
O paralelismo de dados foca na
distribuição de subconjuntos dos mesmo
dados, por múltiplos núcleos de computação,
e na execução da mesma operação em
cada núcleo.
O paralelismo de tarefas foca na
distribuição de tarefas (threads) em vários
núcleos, e diferentes threads podem estar
operando sobre os mesmo dados.
O paralelismo de dados foca na
distribuição de dados entre os núcleos.
Modelos de Geração de
Multithreads
O suporte aos threads pode ser:
 no nível do usuário (threads de
usuário): suportados acima do
kernel e gerenciados sem o suporte
do kernel.
 ou pelo kernel (threads de kernel):
Suportados e gerenciados
diretamente pelo SO.
Deve existir um relacionamento entre
os dois tipos acima.
Modelos MuitosParaUm
Mapeia muitos threads de nível de
usuário para um thread de kernel.
O gerenciamento dos threads é feito
no espaço do usuário, sendo eficiente.
Todo o processo pode ser bloqueado
se um thread fizer uma chamada de sistema
bloqueadora.
Modelo UmParaUm
Mapeia cada thread de usuário para
um thread de kernel.
Fornece mais concorrência que o
muitos-para-um.
Permite que múltiplos threads sejam
executados em paralelo em
multiprocessadores.
Desvantagem: a criação de um thread
de usuário requer a criação de um thread de
kernel.
Modelos MuitosParaMuitos
Multiplexa muitos threads de usuário
para um número menor ou igual de threads
de kernel.
Permite que o desenvolvedor crie
quantos threads o usuário quiser, mas não
resulta em uma concorrência real, pois o
kernel pode incluir no schedule apenas um
thread por vez.
Uma de suas variações multiplexa
muitos threads de usuário para um número
menor ou igual de threads de kernel, mas
também permite que um thread de nível de
usuário seja limitado a um thread de kernel.
Essa variação é, às vezes referenciada como
modelo de dois níveis.
Bibliotecas de threads
Uma biblioteca de threads fornece ao
programador uma API para criação e
gerenciamento de threads. Há duas maneiras
principais de implementá-las: Primeiro,
fornecer uma biblioteca inteiramente no
espaço do usuário sem suporte do kernel, em
que todo o código e estrutura de dados dela
estão no espaço do usuário. A segunda forma
é a implementação de um biblioteca no nível
do kernel com suporte direto do SO.
Três bibliotecas de threads principais
são usadas atualmente: a Pthreads do POSIX,
a do Windows e a de Java.
Duas estratégias gerais para a criação
de múltiplos threads é a síncrona e assíncrona.
Na criação de threads assíncrona,
cada thread é executado de forma
independente e o pai não precisa saber
quando o filho terminou. Geralmente há
pouco compartilhamento de dados entre
eles.
Na criação de threads síncrona, o pai
precisa esperar que todos os filhos terminem
para ele voltar a ser executado (estratégia
conhecida como forkjoin).
Threading Implícito
Com o crescimento do processamento
multicore, aplicações contendo muitas
threads estão surgindo, mas projetar essas
aplicações não é algo simples.
Uma forma de tornar isso mais simples é
transferindo a criação e o gerenciamento de
threads dos desenvolvedores para os
compiladores e bibliotecas de tempo de
execução. Essa estratégia é chama de
Threading Implícito. Há três alternativas para
os o projeto de programas multithreads que
tiram proveito de processadores multicore por
meio do threading implícito.
 Pool de Threads
Criação de múltiplos threads na
inicialização do processo, bem como a
inserção dos threads em um pool, onde eles
ficarão esperando para entrar em ação.
Quando o serviço terminar a ação, ele
retorna para o pool. Se o pool não tem thread
disponível, ele espera.
Isso resolve o problema do gasto do
tempo de criação para threads, a falta ade
aproveitamento dele depois e evita que os
recursos do sistema sejam exauridos.
OpenMP
Conjunto de diretivas de computação
assim como uma API para programas escritos
em C, C++ ou FORTRAN.
Ele identifica regiões paralelas como
blocos de códigos que podem ser
executados em paralelo, permite que os
desenvolvedores escolham entre vários níveis
de paralelismo e permite que os
desenvolvedores identifiquem se os dados
são compartilhados entre threads ou se são
privados de um thread.
Grand Central Dispatch
Também chamado de GCD é uma
tecnologia para SOs Mac OS X e IOS da
Apple. Ele é uma combinação de extensões
para a linguagem C, uma API e uma
biblioteca de tempo de execução que
permite aos desenvolvedores de aplicações
identificarem seções de códigos a serem
executados em paralelo.
Outras Abordagens
Incluem bibliotecas paralelas
concorrentes, como Threading Building Blocks
(TBB) da Intel e vários produtos da Microsoft.
Questões Relacionadas com a
Criação de Threads
Chamadas de Sistema Fork() e Exec()
A chamada de sistema fork ( ) é usada
para criar um processo duplicado separado.
A semântica dessas chamadas muda
em um programa com múltiplos threads.
Se o thread em um programa chamar
fork ( ), o novo processo duplicará todos os
threads, ou o novo processo será um púnico
thread. Alguns sistemas UNIX têm duas versões
de fork ( ), uma para cada uma dessas
opções.
Se um thread chamar exec ( ), o
programa especificado como parâmetro
substituirá o processo inteiro – inclusive nos
UNIX, um sinal é usado para mostrar que
determinado evento ocorreu. O sinal pode ser
síncrono ou assíncrono e seguem o mesmo
padrão:
 Um sinal é gerado pela ocorrência
de um evento específico.
 O sinal é liberado para um
processo.
 Uma vez liberado, ele deve ser
manipulado.
Dois manipuladores possíveis de sinais:
 Um manipulado default.
 Um manipulador definido pelo
usuário.
Para onde o sinal deve ser liberado:
 Para o thread ao qual ele é
aplicável.
 Para cada thread do processo
 Para certos threads do processo
 Designar um thread específico para
receber todos os sinais do processo.
Cancelamento de Threads
Envolve o encerramento de um thread
antes de ele ser concluído.
Um thread a ser cancelado é
chamado de thread-alvo.
O cancelamento pode ocorrer em dois
cenários:
 Cancelamento assíncrono: thread
encerrado imediatamente.
e Geralmente o SO reclama os
recursos do thread cancelado, mas
não todos.
 Cancelamento adiado. É o
cancelamento default
Armazenamento Local do Thread
Algumas vezes, cada thread pode
precisar de sua própria cópia de certos dados
(esses dados são chamados de
armazenamento local do thread ou TLS)
As variáveis locais são visíveis apenas
durante uma única invocação de função,
enquanto os dados TLS são visíveis ao longo
das invocações de funções. A diferença é
que os dados TLS são únicos para cada
thread.
Ativação do Scheduler
Muitos sistemas que implementam o
modelo muito-para-muitos ou de dois níveis
inserem uma estrutura de dados
(normalmente conhecida como peso leve ou
LWP) intermediária entre os threads do usuário
e do kernel.
Para a biblioteca de threads do
usuário, o LWP aparece como um
processador virtual em que a aplicação pode
incluir no schedule um thread de usuário para
execução. Cada LWP é anexado a um
thread do kernel que o SO inclui no schedule
para execução em processadores físicos. Se
um thread do kernel for bloqueado o LWP
também será.
Uma aplicação pode requerer
quantos LWPs quiser para ser executada
eficientemente.
A ativação do schedule é usada para
a comunicação entre a biblioteca de threads
de usuário e o kernel. Nele, o kernel fornece
uma aplicação um conjunto de
processadores virtuais (LWPs), e a aplicação
pode incluir no schedule threads de usuário
para um processador virtual disponível. Além
disso, o kernel deve informar a aplicação
sobre certo eventos (procedimento
chamado de upcall). As upcalls são
manipuladas pela biblioteca de threads com
um manipulador de upcalls que deve ser
executado em um processador virtual.
Exemplos de SOs
Threads no Windows
Uma aplicação no Windows é
executada como um processo separado, e
cada processo pode conter um ou mais
threads. Usa ainda o mapeamento um-para-
um.
Os componentes gerais de um thread:
 ID de identificação
 Conjunto de registradores que
representam o status do
processador
 Uma pilha de usuário, quando
usado thread de usuário e uma
pilha de kernel quando está sendo
executado em modalidade de
kernel.
 Área de armazenamento privada
usada para várias bibliotecas de
tempo de execução e bibliotecas
de links dinâmicos (DLLs).
O conjunto de registradores, as pilhas e
as áreas de armazenamento são chamadas
de contextos do thread.
Principais estruturas de dados de uma
thread:
 ETHREAD – bloco de thread
exclusivo.
 KTHREAD – bloco de thread do
kernel.
 TEB – bloco de ambiente do thread.
Threads no Linux
Fornece a chamada fork ( ) com a
funcionalidade tradicional de duplicar um
processo. Fornece também a chamada
clone ( ) para criar threads. No entanto, o
Linux não diferencia processos e threads. Ele
usa o termo tarefa ao se referir a um fluxo de
controle dentro de um programa.
Antecedentes
Uma situação em que vários processos
acessam e manipulam os mesmos dados e o
concorrentemente e o resultado depende da
ordem em que processo ocorre é chamada
de uma condição de corrida. Para saber a
ordem, é necessária alguma forma de
sincronização.
A Seção Crítica
Cada código tem sua seção crítica em
que o processo pode estar alterando
variáveis comuns, atualizando uma tabela,
gravando um arquivo etc.
Quando um processo está executando
sua seção crítica, nenhum outro processo
deve ter autorização para fazer o mesmo.
Cada processo deve solicitar para
entrar me sua própria seção crítica. A seção
de código que implementa essa solicitação é
a seção de entrada. A seção crítica pode ser
seguida por uma seção de saída. O código
restante é a seção remanescente.
Uma solução para esse problema deve
conter:
  Exclusão mútua
 Progresso
 Espera limitada.
Para isso, dois métodos são usados:
 Kernel com preempção: permite
que um processo seja interceptado
quando está sendo executado em
modalidade de kernel.
Podem apresentar melhor
capacidade de resposta. Mais
apropriado para programação em
tempo real.
 Kernel sem preempção: não
permite que um processo sendo
executado seja interceptado em
modalidade de kernel.
Hardware de Sincronização
Soluções para o problema da seção
crítica usando técnicas que variam do
hardware à APIs baseadas em software.
Todas essas soluções são baseadas na
premissa do trancamento (locking), isto é,
proteção de regiões críticas usando-se de
locks.
O problema da seção crítica é
facilmente resolvível em um computador,
mas não é tão viável em um ambiente
multiprocessador, já que a desabilitação de
interrupções em um multiprocessador pode
ser demorada.
No entanto, muitos sistemas de
computação modernos fornecem instruções
de hardware especiais que permitem testar e
modificar o conteúdo de uma palavra ou
permutar conteúdo de duas palavras
atomicamente (ou seja, como uma unidade
impossível de interromper.
Locks Mutex
As soluções baseadas em hardware
citadas acima, são complicadas e muitas
vezes inacessíveis aos programadores de
aplicações. Como alternativa, os projetistas
de SO constroem ferramentas de software
para resolver isso.
Locks mutex (ou spinlock) são usados
para proteger regiões críticas, evitando
condições de corrida.
Desvantagem: requer a espera em
ação (enquanto um processo está em sua
seção crítica, se outro tentar entrar, pode
ficar esperando em um loop infinito, sendo
claramente um problema em um sistema de
programação real. A espera da ação
desperdiça ciclos da CPU que alguns
processos poderiam usar produtivamente.
Vantagem: nenhuma mudança de
contexto é requerida quando um processo
tem de esperar em um lock, e uma mudança
de contexto pode levar um tempo
considerável.
Assim, os spinlocks são úteis quando o
uso de locks ocorrerá por períodos curtos.
Semáforos
Semelhante ao lock mutex, mas mais
robusto. Quando um processo modifica o
valor do semáforo, nenhum outro processo
pode modificar o valor desse mesmo
semáforo simultaneamente.
Uso e Implementação
Sistemas Operacionais fazem a
distinção entre:
Semáforos de contagem: podem
variar em um domínio irrestrito. Podem ser
usados para controlar o acesso a
determinado recurso composto por um
número finito de instâncias.
Semáforos binários: Varia somente
entre 0 e 1 e se comportam de maneira
semelhante aos locks mutex.
Semáforos também são usados para
resolver vários problemas de sincronização.
Cada semáforo contém um valor
inteiro e um ponteiro para uma lista de PCBs.
Uma forma de adicionar processos da lista e
removê-los da lista, para garantir a espera
limitada, é usando uma fila FIFO, em que o
semáforo contenha ponteiros para a cabeça
e a cauda da fila. Em geral, qualquer
estratégia de enfileiramento pode ser usada.
Deadlocks e Inanição
A implementação de um semáforo
com fila de espera pode fazer com que dois
ou mais processos fiquem esperando
indefinidamente por um evento que pode ser
causado apenas por um dos processos em
espera. Quando tal estado é alcançado,
dizemos que esses processos estão em
deadlock.
 Outro problema relacionado aos
deadlocks é o bloqueio indefinido ou
inanição, que ocorre quando os processos
esperam indefinidamente dentro do
semáforo. Ele pode ocorrer se remover
processos da lista associada a um semáforo,
em ordem LIFO (último a entrar, primeiro a
sair).
Inversão de Prioridades
Um desafio de scheduling ocorre
quando um processo de prioridade mais alta
precisa ler ou modificar dados do kernel que
estão sendo acessados correntemente por
um processo de prioridade mais baixa. Já que
esses processos são protegidos por lock, o
processo de prioridade mais alta precisa
esperar o de prioridade mais baixa terminar.
Se o de baixa prioridade sofrer de
preempção por causa de um processo de
prioridade mais alta, isso tornará as coisas
mais complicadas.
Esse problema é conhecido como
inversão de prioridades, e só ocorre em
sistemas com mais de duas prioridades,
portanto, usar apenas duas prioridades é uma
solução. Mas essa solução não é o suficiente
para muitos SOs, que resolvem isso
implementando um protocolo de herança de
prioridades, em que todos os processos que
estão acessando recursos requeridos por um
processo de prioridade mais alta, herdam a
prioridade mais alta até terminar o uso desses
recursos. Quando termina de usar, sua
prioridade volta ao normal.
Problemas clássicos de
Sincronização
O Problema do Buffer Limitado
A inversão de prioridades pode ser
mais do que inconveniente para o
Scheduling, pois em sistemas com restrições
de tempo rígidas, a inversão de prioridades
pode fazer com que um processo demore
mais do que deveria, acarretando, em
cascata, outras falhas, e resultando em uma
falha do sistema.
O Problema dos Leitores-Gravadores
Existem dois tipos de processos: os
leitores e os gravadores. Se um gravador e
algum outro processo (leitor ou gravador)
acessarem o banco de dados
simultaneamente, pode resultar em caos.
Para tirar essa dificuldade, basta
garantir que gravadores tenham acesso
exclusivo ao Banco de dados, quando foram
utilizá-lo. Esse problema de sincronização é
chamado de problema dos leitores-
gravadores. Eles são usados desde sua
definição, para testar os novos tipos primitivos
de sincronização.
Existem variações desse problema,
mas. No primeiro deles, nenhum leitor deve
esperar que outros leitores terminem, só
porque tem um gravador esperado. No
segundo, se um gravador está esperando,
nenhum novo leitor pode começar a ler.
Uma solução para qualquer um dos
dois problemas pode resultar em inanição. O
primeiro caso, pode causar inanição nos
gravadores, e o segundo, nos leitores.
Esse problema e suas soluções têm sido
generalizados para fornecer locks de leitores-
gravadores em alguns sistemas. A aquisição
de um desses lock requer a especificação da
modalidade do lock: acesso à leitura ou à
gravação.
Vários processos são autorizados a
adquirirem concorrentemente esses locks na
modalidade de leitura, mas só um de
gravação, já que o acesso é exclusivo para
este.
Utilidade locks leitores-gravadores:
 Aplicações em que é fácil
identificar processos que apenas
leem dados compartilhados e
processos que apenas gravam
dados compartilhados.
 Em aplicações que têm mais
leitores do que gravadores.
Problema dos Filósofos Comensais
Cinco filósofos compartilham uma
mesa circula rodeada por cinco cadeiras,
uma para cada. No centro da mesa, há uma
tigela de arroz e a mesa está posta com cinco
chopstick individuais. Periodicamente, um
filósofo fica com fome e tenta pegar os dois
chopsticks que estão mais próximos (um a
direita e um a esquerda. Ele não pode pegar
um que já esteja na mão de um vizinho. Um
filósofo só larga os dois chopsticks depois que
termina de comer.
 Esse problema é um clássico problema
de sincronização, sendo uma simples
representação da necessidade de alocar
vários recursos entre diversos processos de
uma forma livre de deadlock e inanição.
Uma solução simples, é representar
cada chopstick com um semáforo. Embora
isso garanta que dois vizinhos não comam
simultaneamente, ela é rejeitada por criar um
deadlock. Se todos ficarem com fome ao
mesmo tempo e pegarem o chopstick
esquerdo, todos os elementos de chopstick
serão iguais a zero, e quando eles tentarem
pegar o chopstick direito, ficará em estado
de suspensão indefinidamente.
Solução para os deadlock:
 Permitir no máximo quatro filósofos
sentados à mesa simultaneamente.
 Permitir que um filósofo pegue seus
chopstick apenas se os dois
estiverem disponíveis (para isso,
usaria seção crítica).
 Usar solução assímetrica (um
filósofo de número ímpar pega
primeiro o chopstick esquerdo e
depoi o direito, enquanto um
filósofo par pega primeiro o
esquerdo e depois o direito.
Qualquer solução satisfatória garante a
possibilidade que um deles morra de fome,
não garantindo deadlock, mas deixando
sujeito à inanição.
Monitores
Erros de timing podem ocorrer ao usar
semáforos. Para lidar com eles, pesquisadores
desenvolveram construtores de linguagem de
alto nível. Nesse caso, será mostrado o
monitor.
Uso
Um tipo de dados abstrato (ADT)
encapsula dados com um conjunto de
funções para operarem sobre esses dados,
que são independentes de qualquer
implementação específica do ADT.
Um tipo monitor é um ADT que inclui um
conjunto de operações – definidas pelo
programador – e que são de exclusão mútua
dentro do monitor. Ele também declara
variáveis cujo valores definem o estado de
uma instância desse tipo, além dos corpos de
funções que operam sobre essas variáveis.
Sua representação não pode ser
usada diretamente pelos diversos processos,
portanto, uma função definida dentro de um
monitor pode acessar somente as variáveis
locais e seus parâmetros formais. Da mesma
forma, as variáveis locais são acessadas
apenas pelas funções locais.
O construtor monitor assegura que um
processo de cada vez esteja ativo dentro
dele, mas, até aqui, ele não é
suficientemente poderoso para modelar
alguns esquemas de sincronização. Para isso,
mecanismos de sincronização adicionais
precisam ser definidos. Estes mecanismos são
fornecidos pelo construtor condition. Um
programador que precise escrever um
esquema de sincronização personalizado
pode definir uma ou mais variáveis do tipo
condition.
Solução para Filósofos Comensais com
Monitor
Essa solução impõe a restrição de que
um filósofo só possa pegar seu chopstick se os
dois estiverem disponíveis, sendo possível que
um deles morra de inanição.
Monitor usando semáforo
Nesse caso, a exclusão mútua de um
monitor é assegurada.
Retomando Processos dentro de um monitor
Uma solução para determinar qual dos
processos suspensos deve ser retomado é usar
a ordem FCFS (primeiro a entrar, primeiro a ser
atendido), para que o processo que tenha
esperado mais tempo seja retomado
primeiro. Em muitas circunstâncias um
esquema de Scheduling tão simples não é
adequado. Por isso, o construtor de espera
condicional pode ser usado.
O conceito de monitor não garante
que a sequência de acesso anterior seja
seguida.
Problemas que podem ocorrer:
 Um processo pode acessar um
recurso sem antes obter permissão
para isso.
 Um processo pode nunca liberar
um recurso após ter acesso a ele.
 Um processo pode tentar liberar um
recurso que nunca solicitou.
  Um processo pode solicitar o
mesmo recurso duas vezes, sem
liberá-lo antes.
Exemplos de Sincronização
No Windows
O Windows é um kernel multithread e
dá suporte a aplicações de tempo real e a
múltiplos processadores.
Em um sistema uniprocessado, quando
o kernel acessa um recurso global, as
interrupções são mascaradas
temporariamente.
Em sistemas multiprocessados, ele
protege o acesso a recursos globais usando
spinlocks. Além disso, o kernel assegura que
uma thread nunca sofra preempção
enquanto estiver mantendo um spinlocks.
Para a sincronização de threads fora
do kernel, o Windows oferece objetos
despachantes, em que os threads são
sincronizados de acordo vários mecanismos
diferentes, como locks mutex, semáforos,
eventos e timers.
Os objetos despachantes podem estar
em:
Estado sinalizado: o objeto está
disponível e o thread não será bloqueado ao
adquiri-lo.
Estado não sinalizado: Objeto não
disponível, e o thread será bloqueado ao
tentar adquiri-lo.
Um objeto seção crítica é um mutex de
modalidade de usuário que pode ser
adquirido e liberado sem intervenção do
kernel. Em sistemas multiprocessado, ele usa
primeiro um spinlocks enquanto espera que o
outro thread libere o objeto. Se ele mantiver o
spin por muito tempo, o thread que está
tentando obter o objeto alocará então um
mutex do kernel e abandonará sua CPU.
Sincronização no Linux
Antes da versão 2.6, o Linux era um
kernel sem preempção.
Agora, ele é totalmente preemptível e,
uma tarefa pode sofrer preempção quando
está sendo executada no kernel.
Ele fornece vários mecanismos
diferentes para a sincronização do kernel. A
mais simples é um inteiro atômico. Estes são
particularmente eficientes em situações em
que uma variável inteira precisa ser
atualizada, já que essas operações inteiras
não geram overhead dos lockings. Há
também os lock mutex, para proteger seções
críticas. Usa-se ainda de spinlocks e
semáforos.
Em uniprocessadores: a preempção
do kernel é desativada.
Em multiprocessadores: a preempção
é ativada.
Os spinlocks são usados no kernel
apenas quando um lock é mantido por um
curto tempo. Quando um lock precisa ser
mantido por mais tempo, o mais adequado é
o semáforo ou locks mutex.
No Solaris
Fornece locks mutex adaptativos,
variáveis de condição, semáforos, locks de
leitor-gravador e roletas.
Um mutex adaptativo protege o
acesso a todos os itens de dados críticos. No
Solaris ele é usado para proteger apenas os
dados que são acessados por curtos
segmentos de código.
Os locks de leitor-gravador são usados
para proteger dados que são acessados
frequentemente, mas que são de somente
leitura.
Usa roletas para ordenar a lista de
threads em espera para adquirir um mutex
adaptativo ou locks de leitor-gravador.
Roleta é uma estrutura de fila que
contém os threads trancados de um lock.
Abordagens Alternativas
À medida que o número de núcleos de
processamento aumenta, torna-se cada vez
mais difícil projetar aplicações multithreads
que não apresentem condições de corrida e
deadlocks.
Memória Transacional
Seu conceito teve origem na teoria de
banco de dados, e mesmo assim, é uma
estratégia para sincronização de processos.
Uma transação de memória é uma
sequência de operações atômicas de leitura-
gravação em memória. Se todas as
operações de uma transação são
concluídas, a transação da memória é
confirmada. Caso contrário, as operações
são abortadas e revertidas. Os benefícios da
memória transacional podem ser obtidos por
recursos adicionados a uma linguagem de
programação.
A vantagem desse mecanismo no
lugar dos locks é o que o sistema transacional
– e não o desenvolvedor – é responsável por
garantir a atomicidade. Não é possível a
ocorrência de deadlocks.
A memória transacional pode ser
implementada em software (memória
transacional em software – STM) e hardware
(memória transicional em hardware – HTM)

OpenMP

É considerada mais fácil de usar os que

os locks mutex padrão. Desvantagem: os
desenvolvedores de aplicações ainda
devem identificar possíveis condições de
corrida e proteger adequadamente os dados
compartilhados usam a diretiva de
compilador.

Linguagens de Programação Funcionai

A diferença entre linguagens

imperativas e funcionais é que estas não
mantêm o estado.
Várias linguagens funcionais são
usadas hoje em dia, como por exemplo:
Erlang: suporta a concorrência e é fácil
para ser usada no desenvolvimento de
sistemas paralelos.
Scala: é orientada a objetos. Sintaxe
em grande parta semelhante a Java e C#.