Вы находитесь на странице: 1из 23

Programação Concorrente

 

SOPC

Índice

1.

Introdução

 

1

1.1. Objectivo do Trabalho

1

1.2. Metodologias

 

2

2. Conceitos

4

3. Historial

4

4. Introdução a programação concorrente

4

5. Características

 

5

6. Motivação do Uso da Programação Concorrente

5

7. Propósitos da

Programação Concorrente

5

8. Diferença entre thread e processo

7

9. O problema da partilha de recursos

7

9.1. Propriedades para a exclusão mútua

8

9.2. Obtenção da exclusão mútua

8

Desabilitação

de Interrupções

8

Problemas da

Solução DI/EI

8

Soluções com Busy Wait

9

Lock/Unlock

 

9

Block/Wakeup(P)

9

9.3.

Implementação de mecanismos para exclusão mútua

10

Algorítmica

 

10

Primitivas

11

Sincronizações básicas com semáforos

13

Sincronização tipo lock/unlock:

13

Sincronização tipo block/wakeup(P):

13

10.

Criação estática e dinâmica de processos

14

10.1. Criação

estática

14

10.2. Criação

dinâmica

14

11. Sincronizações

15

12. Deadlocks

15

12.1. Condições para a sua ocorrência

15

12.2. Estratégia para lidar deadlocks

16

12.3. Metodos para tratamento de deadlocks

16

12.4. Detecção e recuperação

17

13.

Vantagens da Programação Concorrente

18

14.

Desvantagens da Programação Concorrente

18

15.

Conclusão

20

16.

Bibliografia

21

17.

Anexos

22

UEM

 

0

Programação Concorrente

SOPC

1.

Introdução

Com o advento dos processadores com dois ou mais núcleos, há um incentivo cada vez maior dos fabricantes de hardware para o desenvolvimento de softwares que utilizam a programação concorrente. A programação concorrente foi usada inicialmente na construção de sistemas operativos. Actualmente, ela é usada para desenvolver aplicações em todas as áreas da computação. Este tipo de programação tornou-se ainda mais importante com o advento dos sistemas distribuídos e das máquinas com arquitectura paralela. No presente trabalho serão apresentados os conceitos e os mecanismos clássicos da programação concorrente.

Neste trabalho de pesquisa, aborda-se a o tema programação concorrente desde as definições básicas, passando-se pelos métodos de implementação desta vertente de programação ate os mecanismos de tratamento dos desconfortos que advêm deste modo contextualizado e necessário de programar, com recurso a linguagem Vp4 1 .

1.1. Objectivo do Trabalho

Objectivos gerais

De modo geral, o trabalho visa aprofundar a compreensão e entendimento sobre o tema

Programação Concorrente para posterior aplicação em actividades afins.

Objectivos específicos

Analisar o conceito Programação Concorrente;

Analisar a motivação e propósito da Programação Concorrente;

Clarificar a especificação do paralelismo na Construção de um Programa Concorrente

Demonstrar a criação e princípio de funcionamento de processos

Elucidar, com recurso a exemplos (apresentados em linguagem Vp4), sobre os problemas e apresentar soluções da programação Concorrente

1 Linguagem de programação concorrente

UEM

UEM 1

1

Programação Concorrente

SOPC

1.2.

Metodologias

Análise comparativa das fontes de informação, nas quais o grupo baseou-se para estruturar e compor o trabalho, sendo a o grau de clareza o critério de selecção.

Repartição de tarefas de investigação pelos integrantes do grupo, na qual, cada membro do grupo recebeu um subtema (tópico) com vista a dinamizar a realização do trabalho. Depois de localizado o teor do tópicos, teve lugar a discussão e censura e, posteriormente, fez-se a integração dos mesmos;

Consultas bibliográficas online, selectivas baseadas no grau de oficialidade do website.

UEM

UEM 2

2

Programação Concorrente

SOPC

Programação Concorrente

UEM

UEM 3

3

Programação Concorrente

SOPC

2. Conceitos

Concorrência – Quando há processamento simultâneo lógico (aparente), requer entrelaçamento

de acções.

Deadlock - Estado de um programa concorrente – depende dos valores das variáveis (explícitas e implícitas). A execução de um comando muda o estado.

Paralelismo – Quando há processamento simultâneo físico. Processo – Execução abstrata de uma instância de um programa.

Sincronização – Quando há exclusão mútua de secções críticas.

Thread (Linha) – é uma forma de um processo dividir a si mesmo em duas ou mais tarefas que podem ser executadas concorrentemente.

3.

Historial

O

surgimento da programação concorrente ocorreu de forma natural devido à evolução dos

sistemas operativos, quando estes passaram a implementar multiprogramação (TANENBAUM, 2003). A multiprogramação permite que diversos processos executem emu ma únicar arquitectura de hardware concorrendo ao uso de seus recursos. Para que isso funcione adequadamente o escalonador de processos do SO deve ser capaz de bloquear e desbloquear processos, a fim de realizar a troca de contexto (TANENBAUM, 2003).

4.

Introdução a programação concorrente

O

termo programação concorrente vem do inglês concurrent programming, onde concurrent

significa acontecendo ao mesmo tempo. Uma tradução mais adequada seria programação concomitante.

Programação concorrente é a actividade de construir um programa contendo múltiplas actividades que progridem em paralelo.

Actividades podem progredir em paralelo de duas maneiras:

UEM

UEM 4

4

Programação Concorrente

SOPC

Sendo realmente executadas em paralelo, cada uma, de posse de um processador diferente ou

Tendo o processador se revezando entre as actividades, de forma que cada actividade possa fazer uso do processador durante um período de tempo e depois espere sua próxima oportunidade de avançar na computação.

Um programa é considerado concorrente quando ele (o próprio programa, durante a sua execução) origina diferentes processos. Esses processos, em geral, irão interagir entre si.

Um programa concorrente pode ser idealizado como se tivesse vários fluxos de execução. Prosseguindo com o exemplo do programador, para realizar agora uma "execução imaginária", este vai necessitar de vários dedos, um para cada fluxo de controle (TOSCANI et al.,2003).

5. Características

Composta por um conjunto de processos sequenciais que se executam concorrentemente;

Processos disputam recursos comuns (ex: variáveis, periféricos,etc );

Um processo é dito de cooperante quando á capaz de afectar, ou ser afectado pela execução de outro processo.

6. Motivação do Uso da Programação Concorrente

Facilidade de desenvolvimento de aplicações que possuem paralelismo intrínseco;

Outra motivação para o uso de concorrência é a busca por soluções que permitam que várias partes de um mesmo problema sejam atacadas em paralelo. Com este enfoque, se a plataforma de execução dispor de muitos processadores (o que já é possível com estações de trabalho de custo relativamente baixo), o problema poderá ser resolvido em menos tempo, ou pelo menos soluções parciais úteis ao usuário, poderão ser rapidamente fornecidas

(SARMANHO F.S, 2009).

7. Propósitos da Programação Concorrente

Aproveitar hardware com múltiplos processadores;

Atender a vários usuários simultaneamente;

Melhorar o desempenho das aplicações;

Aumentar a disponibilidade para o usuário;

Manipular objectos activos e controle de actividades;

UEM

UEM 5

5

Programação Concorrente

SOPC

Programas paralelos.

a) Fork/wait ou fork/join

A chamada de sistema fork cria um novo processo (processo filho) a partir de um processo existente (processo pai), onde o código do programa é idêntico (clone).

A execução do processo filho inicia no próximo comando do programa

Processo filho é uma cópia do processo pai, excepto por:

Identificador de processo e identificador de processo pai

Locks obtidos pelo processo pai

Chamada de sistema wait/waitpid é equivalente a primitiva join

– Suspende processo pai até que:

Termine a execução de um processo filho

Processo pai receba um sinal para terminar

– Libera os recursos do processo filho

– Se o processo filho já terminou retorna imediatamente Processo A Fork B Processo B
– Se o processo filho já terminou retorna imediatamente
Processo A
Fork B
Processo B
Fork C
Processo C
Wait C
Bloqueado
wait

wait

Figura 2: Fork/wait ou fork join. (Oliveira et all, 2003)

b) Parbegin/parend

Comandos

concorrentemente.

executados

para

definir

uma

sequencia

de

comandos

a

serem

executados

UEM

UEM 6

6

Programação Concorrente

SOPC

PARBEGIN: especifica que a seqüência seja executada concorrentemente em ordem

imprevisível;

PAREND: ponto de sincronização, quando os processo ou threads terminarem

Processo A de sincronização, quando os processo ou threads terminarem Parbegin Processo B Tarefa B Tarefa C Processo

Parbegin Processo B Tarefa B Tarefa C Processo C Parend Bloqueado
Parbegin
Processo B
Tarefa B
Tarefa C
Processo C
Parend
Bloqueado

Figura 2: Parbegin/parend (Oliveira et all, 2003)

8.

Diferença entre thread e processo

O

que melhor distingue uma thread de um processo é o espaço de endereçamento.

Todas as threads de um processo trabalham no mesmo espaço de endereçamento, que é a memória lógica do “processo hospedeiro”.

Isto é, quando se tem um conjunto de threads dentro de um processo, todas as threads executam

o código do processo e compartilham as suas variáveis. Por outro lado, quando se tem um

conjunto de processos, cada processo trabalha num espaço de endereçamento próprio, com um

conjunto separado de variáveis.

No caso de um processo com N threads, tem-se um único registro descritor (o registro do processo hospedeiro) e N mini-descritores de threads. O mini descritor de cada thread é usado para salvar os valores dos registos da unidade central de processamento.

9. O problema da partilha de recursos

O acesso a recursos compartilhados deve ser feito de forma a manter um estado coerente e correcto do sistema (Oliveira et all., 2003) (Ex: Fila de impressão)

UEM

UEM 7

7

Programação Concorrente

SOPC

9.1. Propriedades para a exclusão mútua

A

apenas um processo é permitido estar dentro de sua R.C. num dado instante.

Nenhum processo que executa fora de sua região crítica pode bloquear outro processo

(ex: processo pára fora da sua R.C.).

Nenhuma suposição pode ser feita sobre as velocidades relativas dos processos ou sobre

o

número

de CPUs 2 no sistema.

Nenhum processo pode ter que esperar eternamente para entrar em sua R.C. ou lá ficar

eternamente.

9.2. Obtenção da exclusão mútua

Pode ser obtida através da

Desabilitação de interrupções;

Variáveis do tipo lock

Alternância de execução

Desabilitação de Interrupções

Usa um par de instruções do tipo DI / EI.

DI = disable interrupt EI = enable interrupt

processo desativa todas as interrupções imediatamente antes de entrar na sua R.C.,

reativando-as imediatamente depois de sair dela.

Com as interrupções desativadas, nenhum processo que está na sua R.C. pode ser

interrompido, o que garante o acesso exclusivo aos dados compartilhados.

Problemas da Solução DI/EI 3

É

desaconselhável dar aos processos de usuário o poder de desabilitar interrupções.

Não funciona com vários processadores.

Inibir interrupções por um longo período de tempo pode ter conseqüências danosas. Por

exemplo, perde-se a sincronização com os dispositivos periféricos.

2 Unidade Central de Processamento 3 DI/DE – Desabilitar interrupção e habilitar instruções

UEM

UEM 8

8

Programação Concorrente

SOPC

OBS: inibir interrupções pelo tempo de algumas poucas instruções pode ser conveniente

para o kernel (p.ex., para atualizar uma estrutura de controle).

Soluções com Busy Wait Busy wait = espera ativa ou espera ocupada.

Basicamente o que essas soluções fazem é: Quando um processo quer entrar na sua R.C. 4 ele

verifica se a entrada é permitida. Se não for, ele espera em um laço (improdutivo) até que o

acesso seja liberado.

Ex: While (vez == OUTRO) do {nothing};

Consequência: desperdício de tempo de CPU.

Alternância Estrita

- Variável global indica de quem é a vez na hora de entrar na R.C.

Lock/Unlock Um processo só entra num trecho delimitado pelo par lock/unlock se nenhum outro processo está

executando em um outro trecho delimitado dessa maneira. Isto é, o primeiro processo que

executa o comando lock passa e tranca a passagem (chaveia a fechadura) para os demais. O

comando unlock deixa passar (desbloqueia) o primeiro processo da fila de processos que estão

bloqueados por terem executado um lock (enquanto a fechadura estava trancada). Se a fila está

vazia, a fechadura é destrancada (isto é, é deixada aberta).

Block/Wakeup(P)

Quando um processo P executa o comando block, ele se bloqueia até que um outro processo

execute o comando wakeup(P). Este último comando acorda (desbloqueia) o processo

especificado por P. Se wakeup(P) é executado antes, o processo P não se bloqueia ao executar o

block. Na linguagem Vale4, o argumento de wakeup pode ser um nome de processo ou um

número único de processo ou thread.

4 Resposta controlada

UEM

UEM 9

9

Programação Concorrente

SOPC

Na verdade, os comandos lock e unlock não formam uma estrutura sintática (isto é, não precisam

estar casados, como se fossem um abre e fecha parênteses), eles são comandos independentes.

Na linguagem Vale4, as operações lock e unlock também podem ser referidas pelos nomes

mutexbegin e mutexend, respectivamente.

9.3. Implementação de mecanismos para exclusão mútua

Algorítmica Existe uma combinação de variáveis do tipo lock e alternância. Temos os seguintes algoritmos:

Algoritmo de Decker Trata-se da primeira solução correta para o problema da exclusão mútua de dois processos

(proposta na década de 60).

Algoritmo de Decker resolve o problema da exclusão mútua

- Uma solução deste tipo só é aceitável se houver um número de CPUs igual (ou superior) ao

número de processos que se devam executar no sistema. Porquê?

- Poderíamos nos dar 'ao luxo' de consumir ciclos de CPU,

- Situação rara na prática (em geral, há mais processos do que CPUs)

- Isto significa que a solução de Dekker é pouco usada.

Algoritmo de Peterson Proposto em 1981, é uma solução simples e elegante para o problema da exclusão mútua, sendo

facilmente generalizado para o caso de n processos.

- O truque do algoritmo consiste no seguinte:

Ao marcar a sua intenção de entrar, o processo já indica (para o caso de empate) que a vez é do

outro.

- Mais simples de ser verificado

UEM

UEM 10

10

Programação Concorrente

SOPC

Programação Concorrente SOPC Exclusão mútua é atingida. - Uma vez que P0 tenha feito flag[0] =

Exclusão mútua é atingida.

- Uma vez que P0 tenha feito flag[0] = true, P1 não pode entrar na sua R.C.

- Se P1 já estiver na sua R.C., então flag[1] = true e P0 está impedido de entrar.

Bloqueio mútuo (deadlock) é evitado.

- Supondo P0 bloqueado no seu while, isso significa que flag[1] = true e que turn = 1

- se flag[1] = true e que turn = 1, então P1 por sua vez entrará na sua seção crítica

Assim, P0 só pode entrar quando ou flag[1] tornar-se false ou turn passar a ser 0.

Primitivas

Mutex Para este existe:

Uma variável compartilhada de acesso a secção crítica. Para o uso deste método

processadores são projectados tendo em conta a possibilidade do uso de muiltiplos

processos;

UEM

UEM 11

11

Programação Concorrente

SOPC

Inclui duas instruções assembly 5 para leitura e escrita de posições assembly para leitura e

escrita de posições de uma memória de forma atómica.

CAS: Compare and store- que copia o valor de uma posição de memória para um

registrador interno e escreve nela o valor 1

TSL: test and set lock- lê o valor de uma posição de memória e coloca nela um valor

não 0.

O emprego de mutex necessita duas primitivas:

Lock e unlock

Enter_region:

tst register,flag Cmp register, 0 Jnz enter,region ret

Leave_region: mov flag,0 ret

Secção critica

ret Leave_region: mov flag,0 ret Secção critica lock(flag); unlock(flag); Problemas do lock e unlock: •

lock(flag);

unlock(flag);

Problemas do lock e unlock:

Busy waiting(spin lock)

Semáforos

As

denominadas P e V. 6

semântica:

variáveis

semáforas

apenas duas operações,

Sendo S é uma variável semáfora, as operações P e V têm a seguinte

são

variáveis

especiais

que

admitem

• espera até S ser maior que 0 e então subtrai 1 de S;

P(S) :

• incrementa S de 1.

V(S) :

5 Linguagem de baixo nível com que se escreve programas de computador usando anotacoes humanamente legíveis para o código de maquina que a CPU do computador entende 6 Sendo P e V as iniciais das palavras holandesas Proberen e Verhogen, que significam testar e incrementar, respectivamente.

UEM

UEM 12

12

Programação Concorrente

SOPC

As operações testar S e subtrair 1 (se S > 0) e incrementar S de 1 são executadas de forma

atómica (indivisível), no kernel do Sistema Operativo. Se S = 1 e dois processos executam P(S)

simultaneamente, um dos processos vai ficar bloqueado.

Pode-se fazer analogia entre uma variável semáfora e um vaso contendo bolinhas (berlindes). O

valor numérico do semáforo corresponde ao número de bolinhas dentro do vaso.

Uma operação V corresponde a colocar uma bolinha no vaso. Cada operação P tenta remover

uma bolinha; se nenhuma está disponível, então a operação bloqueia o processo e o coloca numa

fila de espera.

Quando uma bolinha é colocada no vaso (operação V), ela é removida pelo primeiro processo da

fila de espera, o qual prossegue sua execução.

Sincronizações básicas com semáforos As variáveis semáforas permitem implementar os dois tipos básicos de bloqueio, conforme é

explicado a seguir.

Sincronização tipo lock/unlock:

A sincronização do tipo exclusão mútua é implementada através de um semáforo com valor

inicial 1. O acesso exclusivo a n regiões críticas seria implementado como segue:

P1:

.

P(X);

.

.

REGIÃO CRÍTICA; V(X); .

.

.

X : semaphore initial 1

P2:

.

P(X);

.

.

REGIÃO CRÍTICA; V(X); .

.

.

.

.

.

.

P(X);

.

.

Pn:

REGIÃO CRÍTICA; V(X); .

.

.

Sincronização tipo block/wakeup(P):

Este tipo de sincronização é implementado através de um semáforo com valor inicial zero. Por

exemplo, se a operação B do processo P1 deve ser executada após a operação A do processo P2,

programa-se da seguinte maneira:

UEM

UEM 13

13

Programação Concorrente

SOPC

P1:

.

P(Y);

B;

.

.

.

.

.

.

.

.

Y : semaphore initial 0

% block

.

.

.

P2:

.

.

.

A; V(Y); % wakeup(P1)

.

.

.

10. Criação estática e dinâmica de processos

Os processos de um programa concorrente podem ser criados de forma estática ou dinâmica. No primeiro caso, o programa contém a declaração de um conjunto fixo de processos, os quais são activados simultaneamente, no início da execução do programa. No segundo caso, os processos são criados dinamicamente, durante a execução, através de instruções especiais para esse fim.

Os mecanismos vistos até aqui (fork, join e quit) realizam criação dinâmica (e término dinâmico), pois os processos (ou threads) são criados somente quando instruções especiais são executadas. 7

10.1. Criação estática

No caso da criação estática, os processos são declarados explícitamente 8 no programa fonte e vão existir desde o início da execução do programa concorrente. Normalmente, as linguagens de

programação permitem especificar esses processos de duas maneiras: como processos individuais ou como um array 9 de processos.

10.2. Criação dinâmica

É possível declarar explicitamente um modelo (uma forma) para criar processos durante a execução, conforme é ilustrado a seguir. Neste caso tem-se o que se denomina criação dinâmica com declaração explícita de processos.

7 Por exemplo, se a execução não “passa” por uma determinada instrução fork, então a thread correspondente não é criada. 8 A declaração explícita consiste em definir, para cada processo do programa, as suas variáveis locais e o seu segmento de código.

9

UEM

UEM 14

14

Programação Concorrente

SOPC

11. Sincronizações

É comum um processo ter que esperar até que uma condição se torne verdadeira. Para essa

espera seja eficiente, o processo deve esperar no estado bloqueado (sem competir pela UCP).

Dois tipos de bloqueio são considerados básicos:

Bloquear até que um recurso se torne disponível; 10

Bloquear até que chegue um sinal de outro processo.

Estes bloqueios são caracterizados pelas operações básicas lock/unlock e block/wakeup(P),

descritas a seguir. Enquanto o primeiro par (lock/unlock) implementa sincronização do tipo

exclusão mútua, o segundo par implementa uma forma básica de comunicação.

12. Deadlocks

Ocorre quando duas ou mais threads bloqueiam-se em um ciclo vicioso enquanto tentam aceder a

travas sincronizadas necessárias para continuar suas actividades ou seja ficam a esperra por

recursos que jamais serão liberados.

12.1. Condições para a sua ocorrência

Para a ocorrência de um deadlock e necessário que os processos a baixo estejam decorrendo

1. Exclusão mútua

Ocorre quando tudo esta disponível ou atribuído a um único processo.

2. Segura ou espera Ocorre quando os processo que detêm solicitam novos recursos.

3. Recurso não preemtivel Este é um recurso concedido que não pode ser retirado para outro processo.

4. Espera circular A existência de um ciclo com dois os mais processos cada um esperando por um recurso já adquirido pelo próximo processo do ciclo.

10 O recurso pode ser, inclusive, o direito de acessar os dados compartilhados.

UEM

UEM 15

15

Programação Concorrente

SOPC

12.2. Estratégia para lidar deadlocks

Ignorar

Detecção e recuperação Monitoração de recursos liberados e alocados Eliminação de processos

Impedir a ocorrência cuidando na alocação de recursos Usando o algoritmo do banqueiro

Prevenção por construção Evitar a ocorrência de pelo menos uma das quatro condições para sua ocorrência.

12.3. Metodos para tratamento de deadlocks

Evitar deadlocks

Segundo Coffman, as quatro condições devem estar presentes para um deadlock ocorrer. A

ausência de uma condição impede a ocorrência de deadlock. Portanto, previne-se situações de

deadlock eliminando-se pelo menos uma das condições necessárias para sua ocorrência.

Prevenção de deadlocks

Não preempção: Ocorre quando os recursos não podem ser confiscados temporariamente

para serem alocados a outros processos. Elimina-se esta condição se os recursos forem

ordenados e os processos devem requisitar os recursos em uma sequência que respeite

esta ordenação.

Exclusão mútua: o processo solicita o recurso para uso de forma mutuamente exclusiva.

Esta condição sera eliminada se o processo solicitar todos os recursos que necessita em

uma única vez.

Espera circular: Quando for possível a formação de um ciclo no qual cada processo está

bloqueado à espera de recursos que estão alocados para outros processos de mesmo ciclo.

Esta condição é eliminada se for construído um grafo e se for verificado, para cada

UEM

UEM 16

16

Programação Concorrente

SOPC

requisição, se o atendimento não levará o sistema a um estado não seguro. As requisições

que levarem o sistema a um estado não seguro ou de deadlock não deverão ser atendidas.

Espera por recursos: Os processos possuem recursos enquanto esperam por recursos

adicionais. Um processo pode requisitar e liberar recursos, mas quando requisitar um

recurso não disponível deve liberar os que estava utilizando e, então solicitar todos

coletivamente

12.4.

Detecção e recuperação

É possível, pela análise dos grafos, determinar se existe um deadlock.

Uma maneira simples de examinar grafos para determinar se existe deadlock ë a redução dos mesmos.

Recuperação de deadlock

Quando o algoritmo de detecção de deadlock determina a existência de um deadlock, são possíveis diversas ações como:

a) Terminação de processos

Terminar todos os processos. Esta ação implica em reexecução do processo eliminado.

Assim:

Escolher uma vítima por vez até que o deadlock seja eliminado;

Escolher criteriosamente o processo a ser terminado;

Reexecutar o algoritmo de detecção.

Problema da reexecução de um processo: nem sempre é possível ex. atualização de base de dados.

b) Preempção 11 de recursos

Ocorre quando recursos são retirados de processos no ciclo e entregues a outros, no mesmo ciclo, até que o deadlock seja eliminado. O problema a ser resolvido é a definição de critérios para a escolha da vítima.

c) Rollback

Os processos possuem checkpoints em que, periodicamente, o estado é gravado em um arquivo (imagem de memória, recursos);

Quando um deadlock é detectado, o processo é rolledback até antes de pedir um recurso;

O recurso é atribuído a um outro processo no ciclo.

11 Preempção é, literalmente, direito a preferência

UEM

UEM 17

17

Programação Concorrente

SOPC

13. Vantagens da Programação Concorrente

Aumento de desempenho:

Permite a exploração do paralelismo real disponível em máquinas multiprocessadoras;

Sobreposição de operações de E/S 12 com processamento;

Facilidade de desenvolvimento de aplicações que possuem um paralelismo intrínseco.

14. Desvantagens da Programação Concorrente

Dificuldade de programação tratamento de threads

Ao utilizar o paradigma concorrente, o programador poderá utilizar vários recursos, o mais conhecido são os threads (processos leves), que dividem o trabalho que necessita ser realizado em duas ou mais partes. Dessa forma o processador não necessita aguardar o término de uma instrução para iniciar outra como ocorre no paradigma estruturado clássico, pode-se iniciar no mínimo duas tarefas simultaneamente quando utilizamos um processador de núcleo duplo. Mas para a utilização desses threads é estritamente necessário um controle rigoroso dos componentes utilizados por ela, pois como estarão sendo executados dois ou mais processos que pertencem a uma mesma aplicação, corremos o risco de um comando de um thread requisitar acesso a uma região da memória que já está utilizada por outra. Isso causaria no pior caso uma interrupção repentina na execução do programa, podendo levar à perda de informações importantes contidas na memória de execução que ainda não haviam sido gravadas em um lugar definitivo. O grande empecilho na adoção da programação concorrente está no excesso de esforço necessário por parte do programador para acompanhar e controlar as modificações ou acessos que esses threads fazem ao longo do programa.

 

12 Entrada e saida

UEM

 

18

Programação Concorrente

SOPC

Sincronização Condicional É um método comum para o controle dos threads. Para que um thread não interfira em outro,

usa-se dois tipos de sinal, o WAIT (espere) e o NOTIFY (sinal para prosseguir). Supondo uma

situação onde dois threads possuam trecho de código que instrui para acessar uma mesma área de

memória, o primeiro thread teria de emitir o sinal WAIT para a segunda, e assim que realizasse

todas as operações necessárias com aquela área da memória, enviaria o NOTIFY para o segundo

thread iniciar seu acesso. Isso seria a situação ideal. Porém não é assim que ocorre em algumas

implementações do UNIX 13 . Dependendo da implementação pode haver uma perda de sinal

entre os threads causando a não-execução de determinada tarefa por uma das threads,

impactando todo o andamento da aplicação.

13 Sistema de exploração multi-usuario, multitarefa desenvolvido por Ken Thompson

UEM

UEM 19

19

Programação Concorrente

SOPC

15. Conclusão Terminado o trabalho, concluímos que a programação concorrente é uma modalidade de programação que mostra-se ainda carente de base de hardware instalada para alavancar o desenvolvimento em larga escala de sistemas concorrentes. Contudo, é possível o desenvolvimento de software em paradigma de programação concorrente para um processador com apenas um núcleo, contudo não é aí que o paradigma terá o seu uso optimizado. Nota – se também que esta modalidade de programação é extremamente exigente dado que traz uma significante bagagem de dificuldade de controlo de privilégios de threads, entretanto, mostra-se constituir uma área Aida pouco explorada. Apesar das linguagens de programação oferecerem bibliotecas e compiladores para o desenvolvimento, porém não há grande interesse na mudança de paradigma, afigura-se árduo ainda hoje encontrar entidades que facilitem o paradigma estruturado, pois a programação concorrente exige tempo, investimento em treinamento, depuração e testes maiores. Adicionalmente, não há uma disseminação em larga escala de processadores de vários núcleos, a grande maioria dos computadores do mundo utiliza apenas um núcleo de processamento. Isso também desmotiva o desenvolvedor a mudar de paradigma, pois seu produto não será utilizado da maneira que foi projectada, ou não terá o mesmo desempenho.

UEM

UEM 20

20

Programação Concorrente

SOPC

16.

Bibliografia

[CON63]

CONWAY, M. E. A Multiprocessor system design. Proc. AFIPS Fall Joint Computer Conference, pp.139-146. Las Vegas, Nevada, 1963.

[COU71]

COURTOIS, P. J., HEYMANS, F.and PARNAS, D. L. Concurrent Control with Readers and Writers. Comm. ACM 14, No. 10 (October), 667-668, 1971.

[TOS03]

TOSCANI,

S.,

OLIVEIRA,

R.,

CARISSIMI,

A.,

Sistemas

Operacionais

e

Programação Concorrente. Série didática do II-UFRGS, 2003.

 

[TOS04]

TOSCANI,

S.

S.

Kit

de

instalação

da

linguagem

VALE4.

Disponível

em

UEM

UEM 21

21

Programação Concorrente

SOPC

17.

Anexos

UEM

UEM 22

22