Apresentados os v´arios esquemas seguros de sincronismo pass´ıveis de realiza¸c˜oes autom´aticas pelo sistema de compila¸c˜ao ´e necess´ario agora tratar o problema de se expressar a sua escolha em programas concorrentes.
Escolhas pr´e-definidas na linguagem
Esta op¸c˜ao ´e de longe a mais frequente. ´E a seguida, por exemplo, pela linguagem Ada95 em que os objectos partilhados (protected types) s˜ao sincronizados de uma forma segura com o mecanismo de sincronismo de exclus˜ao leitores-escritor [Ada95 95].
Outra hip´otese mais flex´ıvel ser´a definir na linguagem diferentes anota¸c˜oes (no sis- tema de tipos) para diferentes esquemas de sincronismo, deixando para o programador a escolha do esquema desejado para cada objecto.
-- synchronization keywords: -- monitor, exrw, crw, lockfree
-- class declaration definition:
shared monitor class SHARED OBJECT ...
end
shared exrw class SHARED OBJECT ...
end
shared crw class SHARED OBJECT ...
end
-- mixed synchronization scheme:
shared class SHARED OBJECT
feature lockfree
...
feature exrw
...
end
-- entity declaration definition:
class SOME CLASS ...
feature
a procedure is local
obj: shared crw OBJECT;
do
...
end
...
end
Figura 5.18: Exemplo de escolha directa do esquema sincronismo.
Na figura 5.18 apresenta-se uma aproxima¸c˜ao (em pseudo-Eiffel) em que, para al´em da indica¸c˜ao de partilha de cada objecto (shared), ´e inclu´ıda uma anota¸c˜ao referente `a escolha do sincronismo desejado: monitor para indicar exclus˜ao m´utua; exrw para exclus˜ao leitores-escritor; crw para leitores-escritor concorrentes e lockfree para um sincronismo sem bloqueamento.
Esta aproxima¸c˜ao ´e simples e faz com que a associa¸c˜ao entre os esquemas de sin- cronismo e os objectos partilhados seja directa e evidente. No entanto, ela vai contra um dos objectivos estabelecidos neste trabalho – a sincroniza¸c˜ao abstracta de objectos (sec¸c˜ao 5.9.1) – pelo que n˜ao ser´a uma op¸c˜ao a considerar.
Escolha autom´atica pelo sistema de compila¸c˜ao
Uma op¸c˜ao no sentido da sincroniza¸c˜ao abstracta ´e delegar integralmente a escolha dos esquemas de sincronismo considerados mais apropriados no sistema de compila¸c˜ao. Para essa escolha, o sistema de compila¸c˜ao pode fazer uso de heur´ısticas apropriadas. Por exemplo, caso seja identificada a possibilidade de o sincronismo intra-objecto de um objecto concorrente poder gerar deadlocks, o sistema de compila¸c˜ao pode optar por utilizar, caso seja poss´ıvel, um esquema de sincronismo sem bloqueamento resolvendo, dessa forma, esse problema.
No entanto, esta op¸c˜ao poder´a ser pouco flex´ıvel, j´a que n˜ao permite que o programa- dor possa ter uma palavra a dizer nessa escolha (para mais sabendo-se que n˜ao existem heur´ısticas ´optimas para todas as aplica¸c˜oes poss´ıveis de objectos concorrentes).
PROGRAMA CONFIGURAC¸ ˜AO CONCORRENTE
SISTEMA COMPILAC¸ ˜AO
PROGRAMA EXECUT ´AVEL
Figura 5.19: Esquema da escolha partilhada de sincronismo. Escolha partilhada
Uma terceira possibilidade consiste em partilhar a escolha entre o sistema de com- pila¸c˜ao e o programador. Esta ser´a a aproxima¸c˜ao ideal desde que o sistema de com- pila¸c˜ao n˜ao permita que o programador escolha esquemas inseguros, mas que, ao mesmo tempo, dˆe liberdade para a escolha de um qualquer esquema seguro. Temos assim a jun¸c˜ao do melhor dos dois mundos: a seguran¸ca da escolha est´atica do sincronismo e a flexibilidade da escolha pelo programador do sincronismo mais apropriado para cada objecto.
Para que esta coexistˆencia seja poss´ıvel ´e desej´avel que as eventuais escolhas do programador n˜ao sejam feitas directamente dentro do programa, mas sim numa espe- cifica¸c˜ao separada recorrendo, por exemplo, a uma linguagem externa de configura¸c˜ao e especifica¸c˜ao concorrente do programa.
A figura 5.19 esquematiza esta aproxima¸c˜ao. A configura¸c˜ao concorrente faz uso do c´odigo fonte do programa para identificar sem ambiguidades os objectos concorren- tes para os quais se pretende escolher um determinado sincronismo. Por sua vez, o sistema de compila¸c˜ao necessita quer do programa (obviamente) quer da configura¸c˜ao concorrente para estaticamente verificar se as escolhas feitas s˜ao poss´ıveis, e se assim for, gerar o programa execut´avel.
Na linguagem prot´otipo que tem vindo a ser desenvolvida neste trabalho, pretende- se que a configura¸c˜ao concorrente seja feita recorrendo a uma linguagem de controlo de concorrˆencia. Uma apresenta¸c˜ao dessa linguagem pode ser consultada no cap´ıtulo 6, sec¸c˜ao 6.7.
5.11
Sincroniza¸c˜ao condicional
No contexto das linguagens orientadas por objectos puras, e assumindo uma es- trat´egia de espera (sec¸c˜ao 4.6.3), a sincroniza¸c˜ao condicional ´e um mecanismo, com
eventual bloqueamento, de acesso condicional exclusivo a objectos.
A necessidade deste sincronismo pode resultar exclusivamente de uma condi¸c˜ao interna ao objecto ou, em alternativa, de condi¸c˜oes externas impostas por clientes desse objecto. No primeiro caso a sincroniza¸c˜ao condicional aplica-se sobre o sincronismo intra-objecto, e no segundo sobre o sincronismo inter-objecto.
Ambos os modelos de comunica¸c˜ao entre processadores – envio de mensagens ou partilha de objectos – podem tamb´em requerer mecanismos de sincroniza¸c˜ao condici- onal. Independentemente do modelo, caso a comunica¸c˜ao seja s´ıncrona (sec¸c˜ao 4.5.1) este sincronismo vai impor um bloqueamento no processador que requer a execu¸c˜ao (condicional) de um servi¸co da classe. J´a no caso da comunica¸c˜ao ass´ıncrona, a espera d´a-se na fila das mensagens por tratar associada ao objecto (ou ao processador).
Nesta sec¸c˜ao aborda-se apenas o problema da realizabilidade autom´atica deste sin- cronismo. O problema da escolha dos mecanismos de linguagem que o podem expressar ser´a tratado na sec¸c˜ao 5.14.