Por que você usaria um monitor em vez de um semáforo?

Atualmente, estou participando do curso de programação simultânea em minha universidade e recentemente começamos a falar sobre o conceito de monitor. Embora compreenda a necessidade de exclusão mútua, não entendo por que utilizaria um monitor para isso.

Pelo que entendi, um monitor garante que exatamente um ou nenhum processo esteja na seção crítica o tempo todo. Podemos conseguir exatamente isso com um semáforo. Além disso, implementamos monitores (ou pelo menos uma possibilidade de implementá-los) com semáforos.

Então, por que eu implementaria algo que faz exatamente a mesma coisa que um semáforo com um semáforo? Que benefícios eu recebo?

Eles são quase intercambiáveis ​​e um pode ser construído a partir do outro. É um pouco dependente da linguagem que é implementada / preferida (por exemplo, Java possui monitores embutidos usando a palavra-chave "sincronizar"). No entanto, o semáforo é considerado uma entidade de "nível mais baixo" que o monitor pelos seguintes motivos e diferenças:

Os monitores e os semáforos são usados ​​para a mesma finalidade - sincronização de threads. Porém, os monitores são mais simples de usar que os semáforos, pois lidam com todos os detalhes de aquisição e liberação de bloqueios. Um aplicativo que usa semáforos precisa liberar todos os bloqueios adquiridos por um encadeamento quando o aplicativo termina - isso deve ser feito pelo próprio aplicativo. Se o aplicativo não fizer isso, qualquer outro encadeamento que precise do recurso compartilhado não poderá continuar.

Outra diferença ao usar semáforos é que toda rotina que acessa um recurso compartilhado deve adquirir explicitamente um bloqueio antes de usar o recurso. Isso pode ser facilmente esquecido ao codificar as rotinas relacionadas ao multithreading. Os monitores, ao contrário dos semáforos, adquirem automaticamente os bloqueios necessários. [1]

Veja também a resposta de Stack Overflow, altamente votada, Semaphore vs. Monitors - qual é a diferença? com uma analogia excelente / memorável para banheiros públicos e suportes de bicicleta.

Finalmente discutimos por que você usaria um monitor em vez de um semáforo na palestra de hoje.

Basicamente, tudo se resume a isso: o monitor e o semáforo são igualmente expressivos, o que significa que você pode encontrar uma solução para um problema com um monitor em que originalmente um semáforo era usado e vice-versa.

Bem, nós já sabíamos disso, então por que você usaria um monitor em vez de um semáforo?

Preferência pessoal. Normalmente, um aplicativo de desktop usaria monitores, deixando menos possibilidades de erros, mas, como uma troca, tendo uma estrutura relativamente inchada. Os semáforos, por outro lado, são freqüentemente usados ​​em sistemas operacionais, pois são uma estrutura leve, mas com mais possibilidades de erros.

Acho que podemos concluir que é uma decisão situacional se você precisa ou não deseja usar um monitor ou um semáforo. Se você criar um sistema em tempo real, poderá usar um semáforo; se estiver criando um programa de escritório, também poderá usar um monitor.

Dê uma olhada em, por exemplo, "O livrinho de semáforos"de Allen B. Downey. ele afirma e resolve muitos problemas de sincronização. Verifique particularmente as soluções danificadas e você verá que os semáforos são um mecanismo de nível muito baixo, muito poderoso, mas extremamente fácil de usar mal, onde erros simples têm consecuências terríveis (tornadas ainda piores pela operação não-determinística inerente a programas concorrentes). É fácil esquecer, por exemplo, impor a exclusão mútua, operar no semáforo errado e assim por diante. Os monitores oferecem soluções pré-empacotadas para os casos mais usados ​​e trazem consigo as vantagens da programação orientada a objetos (ou seja, você sabe que a única maneira de mexer com as variáveis ​​gerenciadas pelo monitor é através de suas operações). A desvantagem é que eles não podem ser adaptados facilmente em linguagens não orientadas a objetos,