pthreads mutex vs sémaphore

je vais parler de Mutex vs binaire-sémaphore. Vous utilisez évidemment mutex pour empêcher les données d'un thread d'être accédées par un autre thread en même temps.

(supposons que vous venez d'appeler lock () et que vous êtes en train d'accéder à une donnée. Cela signifie que, vous ne vous attendez pas à ce qu'un autre thread (ou une autre instance du même thread-code) accède aux mêmes données verrouillées par le même mutex. C'est, si c'est le même thread-code obtenir exécuté sur un différentes instances de thread, frappent la serrure, alors la serrure () devrait bloquer le flux de contrôle.)

ceci s'applique à un thread qui utilise un thread-code différent, qui accède également aux mêmes données et qui est également verrouillé par le même mutex.

dans ce cas, vous êtes toujours dans le processus d'accès aux données et vous pouvez prendre, disons, 15 secondes supplémentaires pour atteindre le déverrouillage mutex (de sorte que l'autre thread qui est bloqué dans la serrure mutex se débloquerait et permettrait le contrôle d'accès aux données).

autorisez-vous jamais un autre thread à déverrouiller le même mutex, et à son tour, autorisez le thread qui attend déjà (bloquant) dans la serrure mutex à déverrouiller et accéder aux données? (J'espère que vous avez ce que je dis ici.)

selon la définition universelle convenue,

• avec "mutex" c'est impossible. Aucun autre fil ne peut déverrouiller la serrure dans votre fil
• avec "binaire-sémaphore" cela peut arriver. N'importe quel autre fil peut déverrouiller la serrure dans votre fil

ainsi, si vous êtes très particulier au sujet de l'utilisation du Sémaphore binaire au lieu de mutex, alors vous devriez être très prudent dans la "détermination de la portée" des serrures et des déverrouillages, je veux dire, que chaque flux de contrôle qui frappe chaque serrure devrait frapper un appel de déverrouillage et aussi là ne devrait pas être tout "premier déverrouillage", plutôt il devrait être toujours "première serrure".

mutex est utilisé pour éviter la condition de course entre les fils multiples.

, alors que le sémaphore est utilisé comme élément de synchronisation utilisé dans plusieurs procédés.

mutex ne peut pas être remplacé par un sémaphore binaire car, un procédé attend le sémaphore tandis que l'autre produit Le Sémaphore. Dans le cas mutex l'acquisition et la libération sont traitées par même.

la différence entre semaphore et mutex est la différence entre mécanisme et schéma . La différence réside dans leur but ( intention )et leur fonctionnement( comportemental ).

L' mutex , barrier , pipeline sont parallèle des modèles de programmation . Mutex est utilisé ( prévu ) pour protéger un critical section et assurer mutual exclusion . Barrier permet aux agents(thread/process) de s'attendre les uns aux autres.

L'une des caractéristiques ( behavior ) de mutex est que seul le(s) agent(s) autorisé(s) (processus ou fil) peut entrer dans une section critique et seul le (s) agent (s) peut en sortir volontairement.

il y a des cas où mutex permet l'utilisation d'un seul agent à la fois. Il y a cas où il autorise plusieurs agents(lecteurs multiples) et rejette certains autres agents (rédacteurs).

le semaphore est un mécanisme qui peut être utilisé ( prévu ) pour mettre en œuvre différents modèles. Il est( comportement ) généralement un drapeau (éventuellement protégé par exclusion mutuelle). (Un fait intéressant est même mutex modèle peut être utilisé pour mettre en œuvre sémaphore).

dans la culture populaire, semaphores sont des mécanismes fournis par les noyaux, et mutexes sont fournis par la bibliothèque de l'espace utilisateur.

Note, il y a des idées fausses au sujet de semaphores et mutexes . Il est dit que semaphores est utilisé pour synchronization . Et mutexes a ownership . Cela est dû à des livres OS populaires. Mais la vérité est que tous les Mutex, les sémaphores et les barrières sont utilisés pour la synchronisation . L'intention de mutex n'est pas ownership mais mutual exclusion . Cette idée fausse a donné naissance à la question d'entrevue populaire demandant la différence entre le mutexes et binary-semaphores .

résumé,

• mutex, exclusion mutuelle
• sémaphore, à mettre en œuvre en parallèle des modèles de conception

• mutex, seul le permis d'agent(s) entre critique l'article et uniquement cela(ils) peuvent quitter
• sémaphore, entrez si le drapeau dit d'avancer, sinon attendre jusqu'à ce que quelqu'un change le drapeau

dans la perspective de la conception, mutex ressemble plus à state-pattern où l'algorithme qui est sélectionné par l'état peut changer l'état. Le binary-semaphore est plus comme strategy-pattern où le algorithme externe peut changer l'état et éventuellement l'algorithme / stratégie sélectionné exécuter.

ces deux articles expliquent de grands détails sur mutex vs sémaphores Aussi ce réponse de débordement de pile indique la réponse similaire.

sémaphore est plus utilisé comme drapeau, pour lequel vous n'avez vraiment pas besoin D'apporter RTOS / OS. Le sémaphore peut être modifié accidentellement ou délibérément par d'autres threads (par exemple à cause d'un mauvais codage). Lorsque vous utilisez mutex, il possède les ressources. Aucun autre fil ne peut y accéder avant que la ressource ne soit gratuite.

L'Exemple Des Toilettes

Mutex:

est la clé d'une toilette. Une personne peut avoir la clé - occuper les toilettes - à l'époque. Lorsque vous avez terminé, la personne donne (libère) la clé à la personne suivante dans la file d'attente.

" les mutex sont généralement utilisés pour sérialiser l'accès à une section de code RE-entrant qui ne peut pas être exécuté simultanément par Plus d'un thread. Un objet mutex ne permet qu'un seul thread dans une section contrôlée, forcer les autres threads qui tentent d'accéder à cette section à attendre que le premier thread ait quitté cette section."

(un mutex est en fait un sémaphore de valeur 1.)

sémaphore:

est le nombre de clés de toilette identiques gratuites. Par exemple, disons que nous avons quatre toilettes avec des serrures et des clés identiques. Le compte de sémaphore - le compte de clés - est fixé à 4 Au début (les quatre toilettes sont gratuites), puis la valeur de Compte est décrémenté à mesure que les gens arrivent. Si toutes les toilettes sont pleines, c.-à-d. il n'y a plus de touches libres, le nombre de sémaphores est 0. Maintenant, quand eq. une personne quitte les toilettes, sémaphore est augmenté de 1 (un gratuit), et donné à la personne suivante dans la file d'attente.

"Un sémaphore limite le nombre d'utilisateurs simultanés d'une ressource partagée jusqu'à un nombre maximum. Les Threads peuvent demander l'accès à la ressource (décrémenter le sémaphore), et peuvent signaler qu'ils ont terminé utiliser la ressource (incrémenter le sémaphore)."

Source

ne peuvent être appliqués qu'à des fils dans un seul processus et ne fonctionnent pas entre les processus comme le font les sémaphores.