Bloqueio recursivo (Mutex) vs Bloqueio não recursivo (Mutex)

POSIX permite que mutexes sejam recursivos. Isso significa que o mesmo encadeamento pode bloquear o mesmo mutex duas vezes e não entra em conflito. Obviamente, ele também precisa desbloqueá-lo duas vezes, caso contrário, nenhum outro thread pode obter o mutex. Nem todos os sistemas que suportam pthreads também suportam mutexes recursivos, mas se eles desejam estar em conformidade com POSIX, eles precisam .

Outras APIs (APIs de mais alto nível) também costumam oferecer mutexes, geralmente chamadas de bloqueios. Alguns sistemas / idiomas (por exemplo, Cocoa Objective-C) oferecem mutexes recursivos e não recursivos. Alguns idiomas também oferecem apenas um ou outro. Por exemplo, em Java, os mutexes são sempre recursivos (o mesmo thread pode "sincronizar" duas vezes no mesmo objeto). Dependendo de outras funcionalidades de encadeamento que eles oferecem, não ter mutexes recursivos pode não ser um problema, pois eles podem ser escritos facilmente (eu já implementei os mutexes recursivos com base em operações mais simples de mutex / condição).

O que realmente não entendo: Para que servem os mutexes não recursivos? Por que eu gostaria de ter um bloqueio de thread se ele bloqueia o mesmo mutex duas vezes? Mesmo linguagens de alto nível que poderiam evitar isso (por exemplo, testar se isso causará um impasse e lançar uma exceção, se houver) geralmente não fazem isso. Em vez disso, eles deixarão o bloqueio do encadeamento.

Isso é apenas para casos em que eu bloqueio acidentalmente duas vezes e desbloqueio apenas uma vez e no caso de um mutex recursivo, seria mais difícil encontrar o problema; portanto, tenho um bloqueio imediatamente para ver onde aparece o bloqueio incorreto? Mas não consegui fazer o mesmo com a devolução de um contador de bloqueio ao desbloquear e em uma situação, onde tenho certeza de que soltei o último bloqueio e o contador não é zero, posso lançar uma exceção ou registrar o problema? Ou há outro caso de uso mais útil de mutexes não recursivos que eu falho em ver? Ou talvez seja apenas desempenho, pois um mutex não recursivo pode ser um pouco mais rápido que um recursivo? No entanto, testei isso e a diferença não é tão grande assim.

A diferença entre um mutex recursivo e não recursivo tem a ver com propriedade. No caso de um mutex recursivo, o kernel precisa acompanhar o thread que realmente obteve o mutex na primeira vez, para que ele possa detectar a diferença entre recursão e um thread diferente que deve bloquear. Como outra resposta apontada, há uma questão de sobrecarga adicional disso, tanto em termos de memória para armazenar esse contexto quanto nos ciclos necessários para mantê-lo.

No entanto , há outras considerações em jogo aqui também.

Como o mutex recursivo tem um senso de propriedade, o thread que agarra o mutex deve ser o mesmo thread que libera o mutex. No caso de mutexes não recursivos, não há senso de propriedade e qualquer encadeamento geralmente pode liberar o mutex, não importa qual encadeamento originalmente tenha o mutex. Em muitos casos, esse tipo de "mutex" é realmente mais uma ação de semáforo, em que você não está necessariamente usando o mutex como um dispositivo de exclusão, mas como um dispositivo de sincronização ou sinalização entre dois ou mais threads.

Outra propriedade que vem com um senso de propriedade em um mutex é a capacidade de suportar a herança de prioridade. Como o kernel pode rastrear o encadeamento que possui o mutex e também a identidade de todos os bloqueadores, em um sistema de encadeamento prioritário, é possível escalar a prioridade do encadeamento que atualmente possui o mutex para a prioridade do encadeamento de maior prioridade. que está atualmente bloqueando o mutex. Essa herança evita o problema de inversão de prioridade que pode ocorrer nesses casos. (Observe que nem todos os sistemas suportam herança prioritária em tais mutexes, mas é outro recurso que se torna possível através da noção de propriedade).

Se você se referir ao kernel clássico do VxWorks RTOS, eles definem três mecanismos:

• mutex - suporta recursão e, opcionalmente, herança prioritária. Esse mecanismo é comumente usado para proteger seções críticas de dados de maneira coerente.
• semáforo binário - sem recursão, sem herança, exclusão simples, tomador e doador não precisa ser o mesmo encadeamento, liberação de transmissão disponível. Esse mecanismo pode ser usado para proteger seções críticas, mas também é particularmente útil para sinalização coerente ou sincronização entre threads.
• semáforo de contagem - sem recursão ou herança, atua como um contador de recursos coerente a partir de qualquer contagem inicial desejada; os encadeamentos bloqueiam apenas onde a contagem líquida no recurso é zero.

Novamente, isso varia de acordo com a plataforma - especialmente o que eles chamam de coisas, mas deve ser representativo dos conceitos e dos vários mecanismos em jogo.

A resposta não é eficiência. Mutexes não reentrantes levam a um melhor código.

Exemplo: A :: foo () adquire o bloqueio. Em seguida, chama B :: bar (). Isso funcionou bem quando você o escreveu. Mas algum tempo depois alguém muda B :: bar () para chamar A :: baz (), que também adquire o bloqueio.

Bem, se você não tem mutexes recursivos, esses impasses. Se você os tiver, ele será executado, mas poderá quebrar. A :: foo () pode ter deixado o objeto em um estado inconsistente antes de chamar bar (), supondo que baz () não pôde ser executado porque também adquire o mutex. Mas provavelmente não deveria correr! A pessoa que escreveu A :: foo () assumiu que ninguém poderia chamar A :: baz () ao mesmo tempo - essa é toda a razão pela qual ambos os métodos adquiriram o bloqueio.

O modelo mental certo para usar mutexes: O mutex protege um invariante. Quando o mutex é mantido, o invariante pode mudar, mas antes de liberar o mutex, o invariante é restabelecido. Os bloqueios de reentrada são perigosos porque, na segunda vez que você adquire o bloqueio, não pode mais ter certeza de que o invariante é verdadeiro.

Se você está satisfeito com os bloqueios de reentrada, é apenas porque você não precisou depurar um problema como esse antes. Atualmente, o Java tem bloqueios não reentrantes em java.util.concurrent.locks.

Como escrito pelo próprio Dave Butenhof :

"O maior de todos os grandes problemas com mutexes recursivos é que eles o incentivam a perder completamente o controle de seu esquema e escopo de bloqueio. Isso é mortal. Mal. É o" comedor de threads ". Você mantém os bloqueios pelo menor tempo possível. Período: sempre. Se você está chamando algo com uma trava mantida simplesmente porque não sabe que ela está retida, ou porque não sabe se o receptor precisa do mutex, então está esperando por muito tempo. apontando uma espingarda para o seu aplicativo e pressionando o gatilho. Você provavelmente começou a usar threads para obter simultaneidade; mas acabou de PREVENIR a simultaneidade. "

O modelo mental certo para usar mutexes: O mutex protege um invariante.

Por que você tem certeza de que esse é realmente o modelo mental correto para o uso de mutexes? Eu acho que o modelo certo está protegendo os dados, mas não os invariantes.

O problema de proteger invariantes se apresenta mesmo em aplicativos de thread único e não tem nada em comum com multi-threading e mutexes.

Além disso, se você precisar proteger invariantes, ainda poderá usar o semáforo binário que nunca é recursivo.

Um dos principais motivos pelos quais mutexes recursivos são úteis é no caso de acessar os métodos várias vezes pelo mesmo encadeamento. Por exemplo, digamos que, se o bloqueio mutex estiver protegendo um banco A / c para retirada, se houver uma taxa também associada a esse saque, o mesmo mutex deverá ser usado.

O único bom caso de uso para recursão mutex é quando um objeto contém vários métodos. Quando qualquer um dos métodos modifica o conteúdo do objeto e, portanto, deve bloquear o objeto antes que o estado seja consistente novamente.

Se os métodos usarem outros métodos (por exemplo: addNewArray () chama addNewPoint () e finaliza com recheckBounds ()), mas qualquer uma dessas funções precisa bloquear o mutex, o mutex recursivo é um ganha-ganha.

Para qualquer outro caso (resolver apenas códigos ruins, usá-los mesmo em objetos diferentes) está claramente errado!

Para que servem os mutexes não recursivos?

Eles são absolutamente bons quando você precisa garantir que o mutex esteja desbloqueado antes de fazer algo. Isso ocorre porque pthread_mutex_unlockpode garantir que o mutex seja desbloqueado apenas se não for recursivo.

pthread_mutex_t      g_mutex;

void foo()
{
    pthread_mutex_lock(&g_mutex);
    // Do something.
    pthread_mutex_unlock(&g_mutex);

    bar();
}

Se g_mutexnão for recursivo, o código acima é garantido para ligar bar()com o mutex desbloqueado .

Assim, eliminar a possibilidade de um impasse no caso bar()de ser uma função externa desconhecida que pode muito bem fazer algo que pode resultar em outro encadeamento tentando adquirir o mesmo mutex. Tais cenários não são incomuns em aplicativos criados em conjuntos de encadeamentos e em aplicativos distribuídos, nos quais uma chamada entre processos pode gerar um novo encadeamento sem que o programador cliente perceba isso. Em todos esses cenários, é melhor chamar as funções externas mencionadas somente após o bloqueio ser liberado.

Se g_mutexfosse recursivo, simplesmente não haveria maneira de garantir que ele estivesse desbloqueado antes de fazer uma ligação.