Différence entre le sémaphore binaire et le mutex

ils sont pas la même chose. Ils sont utilisés pour des fins différentes!

Bien que les deux types de sémaphores aient un état complet/vide et utilisent la même API, leur utilisation est très différente.

Sémaphores D'Exclusion Mutuelle

Les sémaphores d'Exclusion mutuelle sont utilisés pour protéger les ressources partagées (structure de données, fichier, etc..).

un sémaphore Mutex est "possédé" par l'équipe qui le prend. Si la tâche B tente de semi-transmettre un mutex actuellement détenu par la tâche A, L'appel de la tâche B retournera une erreur et échouera.

les Mutex utilisent toujours la séquence suivante:

  - SemTake
  - Critical Section
  - SemGive

voici un exemple simple:

  Thread A                     Thread B
   Take Mutex
     access data
     ...                        Take Mutex  <== Will block
     ...
   Give Mutex                     access data  <== Unblocks
                                  ...
                                Give Mutex

Sémaphore Binaire

Le Sémaphore binaire aborde une question totalement différente:

• La tâche B attend que quelque chose se produise (un capteur se déclenche, par exemple).
• déplacements des capteurs et un service D'interruption de Routine. Il doit notifier une tâche du voyage.
• la tâche B doit être exécutée et prendre les mesures appropriées pour le déclenchement du capteur. Alors retournez attendre.

   Task A                      Task B
   ...                         Take BinSemaphore   <== wait for something
   Do Something Noteworthy
   Give BinSemaphore           do something    <== unblocks

noter qu'avec un sémaphore binaire, il est correct pour B de prendre le sémaphore et A de le donner.

Encore une fois, un sémaphore binaire ne protège pas une ressource de l'accès. L'acte de Donner et de Prendre un sémaphore sont fondamentalement découplés.

Il est généralement peu logique pour la même tâche de donner et une prise sur le même sémaphore binaire.

Mutex ne peut être libéré que par le fil qui l'a acquis, alors que vous pouvez signaler Le Sémaphore de n'importe quel autre fil (ou processus), de sorte que les sémaphores sont plus appropriés pour certains problèmes de synchronisation comme producteur-consommateur.

sur Windows, les sémaphores binaires ressemblent plus à des objets d'événement qu'à des Mutex.

L'exemple de la toilette est une analogie agréable:

Mutex:

est la clé d'une toilette. Une personne peut la clé - occuper le wc - au temps. Lorsque vous avez terminé, la personne donne (libère) la clé de la prochaine personne dans la file d'attente.

officiellement: "les mutex sont typiquement utilisé pour sérialiser l'accès à une section du code de rentrée qui ne peut être exécuter simultanément par plus d'un fil. Un objet mutex ne permet qu'un seul fil dans une section contrôlée, forçant d'autres fils qui tentent de accéder à cette section pour attendre jusqu'à ce que le premier fil ait quitté cette section."Réf: Symbian Developer Bibliothèque

(Un mutex est vraiment un sémaphore avec la valeur 1.)

sémaphore:

est le nombre de toilettes identiques gratuites touches. Exemple, disons que nous avons quatre toilettes avec serrures et clés identiques. Le compte de sémaphore - le compte de touches - est mis à 4 Au début (tous quatre toilettes sont libres), puis le comte la valeur est décrémentée que les gens sont venir dans. Si toutes les toilettes sont pleins, IE. il n'y a pas de libre-clés gauche, la le nombre de sémaphores est de 0. Maintenant, quand eq. une personne quitte les toilettes, le sémaphore est augmenté à 1 (1 la clé), et donné à la prochaine personne dans file.

officiellement: "un sémaphore limite la nombre d'utilisateurs simultanés d'un ressource partagée jusqu'à un maximum nombre. Les Threads peuvent demander l'accès la ressource (décrémentant la sémaphore), et peut être le signal qu'ils avez fini d'utiliser la ressource (l'incrémentation du sémaphore)."Ref: Symbian Développeur De La Bibliothèque

bons articles sur le sujet:

• MUTEX VS. SÉMAPHORES-PARTIE 1: SÉMAPHORES
• MUTEX VS. SÉMAPHORES-PARTIE 2: LE MUTEX
• MUTEX VS. SÉMAPHORES-PARTIE 3 (DERNIÈRE PARTIE): PROBLÈMES D'EXCLUSION MUTUELLE

de la partie 2:

le mutex est similaire aux principes du sémaphore binaire avec un différence significative: le principe de la propriété. La propriété est le simple concept que lorsqu'une tâche serrures (acquiert) un mutex seul il peut déverrouiller (libération). Si une tâche essaie de déverrouiller un mutex qu'il n'a pas verrouillé (ainsi ne possède pas) alors une condition d'erreur est rencontrés et, plus important encore, le mutex n'est pas déverrouillé. Si l' l'objet d'exclusion mutuelle n'a pas propriété, puis, indépendamment de ce qu'il être appelé, il n'est pas un mutex.

comme aucune des réponses ci-dessus n'efface la confusion, en voici une qui efface ma confusion.

à proprement parler, un mutex est un mécanisme de verrouillage utilisé pour synchroniser l'accès à une ressource. Une seule tâche (peut être un fil ou processus basé sur l'abstraction OS) peut acquérir le mutex. Cela signifie qu'il y sera la propriété associée à mutex, et seul le propriétaire peut relâchez la serrure (mutex).

sémaphore est le mécanisme de signalisation ("je suis fait, vous pouvez continuer" type de signal). Par exemple, si vous êtes à l'écoute des chansons (à supposer comme une tâche) sur votre mobile et, en même temps que votre ami vous appelle, une interruption sera déclenchée sur laquelle une routine d'interruption de service (ISR) signalera la tâche de traitement des appels à wakeup.

Source: http://www.geeksforgeeks.org/mutex-vs-semaphore/

leur sémantique de synchronisation est très différente:

• les Mutex permettent la sérialisation de l'accès à une ressource donnée, c'est-à-dire que plusieurs threads attendent une serrure, un à la fois et comme il a été dit précédemment, le thread possède la serrure jusqu'à ce qu'elle soit faite: seulement ce thread particulier peut la déverrouiller.
• un sémaphore binaire est un compteur avec des valeurs 0 et 1: une tâche qui bloque dessus jusqu'à toute tâche fait un sem_post. Le sémaphore annonce qu'une ressource est disponible, et il fournit le mécanisme d'attendre jusqu'à ce qu'il est signalé comme étant disponible.

comme tel on peut voir un mutex comme un jeton passé de la tâche aux tâches et un sémaphore comme feu rouge de circulation (il signale quelqu'un qu'il peut procéder).

• A Mutex , par définition, est utilisé pour sérialiser l'accès à une section de code de rentrant qui ne peut pas être exécutée concurremment par plus d'un thread.

• Un Sémaphore , par définition, limite le nombre d'utilisateurs simultanés d'une ressource partagée jusqu'à un nombre maximal

• Un sémaphore peut être un Mutex, mais un Mutex ne peut jamais être sémaphore. Cela signifie simplement qu'un sémaphore binaire peut être utilisé
  
  comme Mutex, mais un Mutex ne peut jamais montrer la fonctionnalité de sémaphore.

• les sémaphores et les Mutex (au moins le dernier noyau) sont de nature non récursive.
• personne ne possède de sémaphores, alors que Mutex en est propriétaire et que le propriétaire en est tenu responsable. C'est un important distinction du point de vue du débogage.

• dans le cas de Mutex, le fil qui possède le Mutex est responsable de le libérer. Toutefois, dans le cas de sémaphores, ce condition n'est pas exigée. Tout autre thread peut signaler de libérer le sémaphore en utilisant la fonction S M P s (.e_ot)

• une autre différence qui serait importante pour les développeurs est que les sémaphores sont à l'échelle du système et restent sous forme de fichiers sur le système de fichiers, sauf indication contraire nettoyé jusqu'. Mutex sont processwide et obtenir nettoyé automatiquement lorsqu'un processus s'arrête.

• la nature des sémaphores permet de les utiliser pour synchroniser des processus apparentés ou non, ainsi qu'entre threads. Mutex ne peut être utilisé que pour la synchronisation entre les fils et tout au plus entre les processus connexes (Le pthread l'implémentation du dernier noyau est livré avec une fonctionnalité qui permet D'utiliser Mutex entre les processus liés).
• selon la documentation du noyau, les Mutex sont plus légers que les sémaphores. Ce que cela signifie, c'est qu'un programme avec l'utilisation de sémaphore a une empreinte mémoire plus élevée par rapport à un programme ayant Mutex.
• du point de vue de L'usage, la sémantique de Mutex est plus simple que celle des sémaphores.

à un niveau théorique, ils ne sont pas sémantiquement différents. Vous pouvez implémenter un mutex en utilisant des sémaphores ou vice versa (voir ici pour un exemple). En pratique, la mise en œuvre est différente et ils offrent des services légèrement différents.

la différence pratique (en termes de services système qui les entourent) est que la mise en œuvre d'un mutex vise à être un mécanisme de synchronisation plus léger. Dans oracle-parler, les mutex sont connus sous le nom de latches et les sémaphores sont connus sous le nom de waits .

Au niveau le plus bas, ils utilisent un certain type de atomique test mécanisme. Cela lit la valeur courante d'un emplacement de mémoire, calcule une sorte de conditionnel et écrit une valeur à cet endroit dans une seule instruction que ne peut pas être interrompu . Cela signifie que vous pouvez acquérir un mutex et tester pour voir si quelqu'un d'autre qu'il avait avant.

une implémentation mutex typique a un processus ou un thread qui exécute l'instruction test-and-set et qui évalue si quelque chose d'autre a configuré le mutex. Un point clé ici est qu'il n'y a pas d'interaction avec le scheduler , donc nous n'avons aucune idée (et ne nous soucions pas) qui a mis la serrure. Ensuite, soit nous abandonnons notre tranche de temps et nous le réessayons lorsque la tâche est programmée, soit nous exécutons un spin-lock . Un verrouillage de spin est un algorithme du type:

Count down from 5000:
     i. Execute the test-and-set instruction
    ii. If the mutex is clear, we have acquired it in the previous instruction 
        so we can exit the loop
   iii. When we get to zero, give up our time slice.

lorsque nous avons terminé l'exécution de notre code protégé (connu sous le nom de section critique ) nous avons juste mis la valeur mutex à zéro ou ce qui signifie 'clair."Si plusieurs tâches tentent d'acquérir le mutex, la prochaine tâche qui sera programmée après la sortie du mutex aura accès à la ressource. Généralement, vous utiliseriez des Mutex pour contrôler un synchronisé ressource dont l'accès exclusif n'est nécessaire que pendant de très courtes périodes, normalement pour mettre à jour une structure de données partagées.

un sémaphore est une structure de données synchronisée (typiquement en utilisant un mutex) qui a un nombre et certains enveloppements d'appels système qui interagissent avec le planificateur un peu plus en profondeur que les bibliothèques mutex. Les sémaphores sont incrémentés et décrémentés et utilisés pour bloquer tâches jusqu'à ce que quelque chose d'autre est prêt. Voir problème producteur / consommateur pour un exemple simple. Les sémaphores sont initialisés à une certaine valeur - un sémaphore binaire est juste un cas spécial où le sémaphore est initialisé à 1. L'affichage d'un sémaphore a pour effet de réveiller un processus d'attente.

un algorithme sémaphore de base ressemble à:

(somewhere in the program startup)
Initialise the semaphore to its start-up value.

Acquiring a semaphore
   i. (synchronised) Attempt to decrement the semaphore value
  ii. If the value would be less than zero, put the task on the tail of the list of tasks waiting on the semaphore and give up the time slice.

Posting a semaphore
   i. (synchronised) Increment the semaphore value
  ii. If the value is greater or equal to the amount requested in the post at the front of the queue, take that task off the queue and make it runnable.  
 iii. Repeat (ii) for all tasks until the posted value is exhausted or there are no more tasks waiting.

Dans le cas d'un sémaphore binaire la principale différence pratique entre les deux est la nature du système services entourant la structure de données.

EDIT: comme evan l'a fait remarquer à juste titre, spinlocks ralentira une machine à processeur unique. Vous n'utiliserez un spinlock que sur une boîte multi-processeurs car sur un seul processeur, le processus contenant le mutex ne le réinitialisera jamais pendant qu'une autre tâche est en cours d'exécution. Les Spinlocks ne sont utiles que sur les architectures multi-processeurs.

bien que mutex & sémaphores soient utilisés comme primitives de synchronisation ,il y a une grande différence entre eux. Dans le cas de mutex, seul le thread qui a verrouillé ou acquis le mutex pouvez le déverrouiller. Dans le cas d'un sémaphore, un fil qui attend sur un sémaphore peut être signalé par un fil différent. Certains supports de système d'exploitation utilisant mutex & sémaphores entre les processus. Typiquement l'usage est la création dans la mémoire partagée.

sur Windows, il y a deux différences entre les mutex et les sémaphores binaires:

1. un mutex ne peut être libéré que par le fil qui a la propriété, c'est-à-dire le fil qui précédemment appelé la fonction Wait, (ou qui a pris la propriété lors de sa création). Un sémaphore peut être libéré par n'importe quel fil.

2. un thread peut appeler une fonction wait de façon répétée sur un mutex sans bloquer. Toutefois, si vous appeler une fonction d'attente deux fois sur un sémaphore binaire sans libérer le sémaphore entre les deux, le fil va se bloquer.

vous utilisez évidemment mutex pour verrouiller une donnée dans un thread accédant à un autre thread en même temps. Supposons que vous avez juste appelé lock() et dans le processus d'accès aux données. 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-à-dire, si c'est le même thread-code qui est exécuté sur une instance de thread différente, qui frappe la serrure, alors le lock() devrait bloquer la 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 le verrou mutex se débloquerait et permettrait au contrôle d'accéder aux données). Est-ce que vous permettez à tout prix encore un autre thread de déverrouiller le même mutex, et à son tour, permettre au thread qui est déjà en attente (blocage) dans la serrure mutex de débloquer et d'accéder aux données? J'espère que tu as compris ce que je dis? Conformément à l'accord de définition universelle!,

• 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

Donc, si vous êtes très en particulier sur l'utilisation de binaire-sémaphore à la place 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, aussi il ne devrait pas y avoir de "premier déverrouillage", il devrait plutôt être toujours "première serrure".

Mutex sont utilisés pour les " Mécanismes de Verrouillage ". un processus à la fois peut utiliser une ressource partagée

attendu que

sont utilisés pour les " mécanismes de signalisation " comme "je suis fait , maintenant peut continuer"

mythe:

Couple de l'article dit que "binaire sémaphore mutex et sont même" ou "Sémaphore avec la valeur 1 est mutex" mais la différence fondamentale est de Mutex ne peut être libéré que par le thread qui l'avaient acquise, alors que vous pouvez le signal sémaphore à partir de n'importe quel autre thread

Points Clés:

•un thread peut acquérir plus d'une serrure (Mutex).

•Un mutex peut être verrouillé plus d'une fois que si son récursive mutex, ici verrouiller et déverrouiller pour mutex devrait être le même

•sémaphore binaire et mutex sont similaires mais pas identiques.

•Mutex est une opération coûteuse en raison des protocoles de protection qui lui sont associés.

•l'objectif principal de mutex est d'atteindre l'accès ou le verrouillage atomique sur la ressource

Un Mutex contrôle l'accès à un seule ressource partagée. Il fournit des opérations à d'acquérir () d'accéder à cette ressource et de libérer () lorsqu'il est fait.

A sémaphore contrôle l'accès à un bassin partagé de ressources. Il fournit des opérations à Wait () jusqu'à ce qu'une des ressources dans la piscine devient disponible, et Signal() quand il est rendu à la piscine.

lorsque le nombre de ressources qu'un sémaphore protège est supérieur à 1, il est appelé un sémaphore de comptage . Quand il contrôle une ressource, il est appelé un sémaphore booléen . Un sémaphore booléen est l'équivalent d'un mutex.

ainsi, un sémaphore est une abstraction de niveau plus élevé que le Mutex. Un Mutex peut être implémenté en utilisant un sémaphore mais pas l'inverse.

Mutex: supposons que nous ayons un thread de section critique T1 veut y accéder alors il suit les étapes ci-dessous. T1:

1. Lock
2. Utiliser La Section Critique
3. Déverrouiller

sémaphore binaire: il fonctionne sur la base de signal d'attente et de signal. attendre(s) diminution de la valeur "s" par un généralement de valeur "s" est l'initialiser avec la valeur "1", signal(s) augmente la valeur "s" par un. si "s" a la valeur 1 signifie que personne n'est en utilisant la section critique, lorsque la valeur est 0 signifie que la section critique est utilisée. supposons que le thread T2 utilise la section critique alors il suit les étapes ci-dessous. T2:

1. wait(s)//d'abord de valeur est l'un après l'appel de l'attendre de la valeur a diminué de un je.e 0
2. utiliser la section critique
3. signal (s) / / maintenant la valeur de s est augmentée et elle devient 1

principale différence entre Mutex et sémaphore binaire est dans Muttext si thread lock la section critique, alors il doit déverrouiller la section critique aucun autre thread ne peut la déverrouiller, mais dans le cas de sémaphore binaire si un thread verrouille la section critique en utilisant la fonction wait(s), alors la valeur de s devient "0" et personne ne peut y accéder jusqu'à ce que la valeur de "s" devienne 1, mais supposons que d'autres thread appellent le signal (S), puis la valeur de "s" devient 1 et cela permet à d'autres fonctions d'utiliser la section critique. par conséquent dans le fil sémaphore binaire n'a pas la propriété.

question modifiée est-Quelle est la différence entre un mutex et un sémaphore "binaire" dans "Linux"?

Ans: voici les différences – I) Scope – le scope de mutex est dans un espace d'adresse de processus qui l'a créé et est utilisé pour la synchronisation des threads. Alors que le sémaphore peut être utilisé à travers l'espace de processus et donc il peut être utilisé pour la synchronisation des processus.

ii) le Mutex est léger et plus rapide que le sémaphore. Futex est encore plus rapide.

iii) Mutex peut être acquis par le même thread avec succès plusieurs fois avec la condition qu'il doit libérer le même nombre de fois. Un autre fil essayant d'acquérir va bloquer. Alors qu'en cas de sémaphore, si le même procédé tente de l'acquérir à nouveau, il bloque car il ne peut être acquis qu'une seule fois.

Mutex travailler sur le blocage de la région critique, mais sémaphore travail sur le compte.

http://www.geeksforgeeks.org/archives/9102 discute en détail.

Mutex est un mécanisme de verrouillage utilisé pour synchroniser l'accès à une ressource. Semaphore est un mécanisme de signalisation.

c'est au programmeur de décider s'il veut utiliser le sémaphore binaire à la place du mutex.

Diff entre le Binaire Sémaphore Mutex et de: PROPRIÉTÉ: Les sémaphores peuvent être signalés (affichés) même par un propriétaire Non actuel. Cela signifie que vous pouvez simplement poster à partir de n'importe quel autre fil, bien que vous ne soyez pas le propriétaire.

sémaphore est une propriété publique en cours, il peut être simplement posté par un fil non propriétaire. Veuillez marquer cette différence en caractères gras, cela signifie beaucoup.

Outre le fait que les mutex ont un propriétaire, les deux objets peuvent être optimisés pour différents usages. Les Mutex ne sont conçus pour être retenus que pendant une courte période; Le non-respect de cette condition peut entraîner de mauvaises performances et des horaires inéquitables. Par exemple, un fil courant peut être autorisé à acquérir un mutex, même si un autre fil est déjà bloqué dessus. Les sémaphores peuvent fournir plus d'équité, ou l'équité peut être forcé en utilisant plusieurs variables de condition.

dans windows la différence est comme ci-dessous. MUTEX: processus qui exécute avec succès wait doit exécuter un signal et vice versa. sémaphores binaires: différents procédés peuvent exécuter wait ou signal opération sur un sémaphore.

le concept était clair pour moi après avoir dépassé les postes. Mais il y avait des questions qui persistaient. Alors, j'ai écrit ce petit morceau de code.

quand on essaie de donner un sémaphore sans le prendre, il passe. Mais, lorsque vous essayez de donner un mutex sans le prendre, il échoue. J'ai testé ça sur une plateforme Windows. Permet à USE_MUTEX d'exécuter le même code en utilisant un MUTEX.

#include <stdio.h>
#include <windows.h>
#define xUSE_MUTEX 1
#define MAX_SEM_COUNT 1

DWORD WINAPI Thread_no_1( LPVOID lpParam );
DWORD WINAPI Thread_no_2( LPVOID lpParam );

HANDLE Handle_Of_Thread_1 = 0;
HANDLE Handle_Of_Thread_2 = 0;
int Data_Of_Thread_1 = 1;
int Data_Of_Thread_2 = 2;
HANDLE ghMutex = NULL;
HANDLE ghSemaphore = NULL;


int main(void)
{

#ifdef USE_MUTEX
    ghMutex = CreateMutex( NULL, FALSE, NULL);
    if (ghMutex  == NULL) 
    {
        printf("CreateMutex error: %d\n", GetLastError());
        return 1;
    }
#else
    // Create a semaphore with initial and max counts of MAX_SEM_COUNT
    ghSemaphore = CreateSemaphore(NULL,MAX_SEM_COUNT,MAX_SEM_COUNT,NULL);
    if (ghSemaphore == NULL) 
    {
        printf("CreateSemaphore error: %d\n", GetLastError());
        return 1;
    }
#endif
    // Create thread 1.
    Handle_Of_Thread_1 = CreateThread( NULL, 0,Thread_no_1, &Data_Of_Thread_1, 0, NULL);  
    if ( Handle_Of_Thread_1 == NULL)
    {
        printf("Create first thread problem \n");
        return 1;
    }

    /* sleep for 5 seconds **/
    Sleep(5 * 1000);

    /*Create thread 2 */
    Handle_Of_Thread_2 = CreateThread( NULL, 0,Thread_no_2, &Data_Of_Thread_2, 0, NULL);  
    if ( Handle_Of_Thread_2 == NULL)
    {
        printf("Create second thread problem \n");
        return 1;
    }

    // Sleep for 20 seconds
    Sleep(20 * 1000);

    printf("Out of the program \n");
    return 0;
}


int my_critical_section_code(HANDLE thread_handle)
{

#ifdef USE_MUTEX
    if(thread_handle == Handle_Of_Thread_1)
    {
        /* get the lock */
        WaitForSingleObject(ghMutex, INFINITE);
        printf("Thread 1 holding the mutex \n");
    }
#else
    /* get the semaphore */
    if(thread_handle == Handle_Of_Thread_1)
    {
        WaitForSingleObject(ghSemaphore, INFINITE);
        printf("Thread 1 holding semaphore \n");
    }
#endif

    if(thread_handle == Handle_Of_Thread_1)
    {
        /* sleep for 10 seconds */
        Sleep(10 * 1000);
#ifdef USE_MUTEX
        printf("Thread 1 about to release mutex \n");
#else
        printf("Thread 1 about to release semaphore \n");
#endif
    }
    else
    {
        /* sleep for 3 secconds */
        Sleep(3 * 1000);
    }

#ifdef USE_MUTEX
    /* release the lock*/
    if(!ReleaseMutex(ghMutex))
    {
        printf("Release Mutex error in thread %d: error # %d\n", (thread_handle == Handle_Of_Thread_1 ? 1:2),GetLastError());
    }
#else
    if (!ReleaseSemaphore(ghSemaphore,1,NULL) )      
    {
        printf("ReleaseSemaphore error in thread %d: error # %d\n",(thread_handle == Handle_Of_Thread_1 ? 1:2), GetLastError());
    }
#endif

    return 0;
}

DWORD WINAPI Thread_no_1( LPVOID lpParam ) 
{ 
    my_critical_section_code(Handle_Of_Thread_1);
    return 0;
}


DWORD WINAPI Thread_no_2( LPVOID lpParam ) 
{
    my_critical_section_code(Handle_Of_Thread_2);
    return 0;
}

les différences entre sémaphore binaire et mutex sont:

Mutex est utilisé exclusivement pour l'exclusion mutuelle. L'exclusion mutuelle et la synchronisation peuvent être utilisées par binaire. Une tâche qui a pris mutex ne peut donner mutex. D'un ISR un mutex ne peut pas être donné. La prise récursive de sémaphores d'exclusion mutuelle est possible. Cela signifie qu'une tâche qui tient avant de finalement libérer un sémaphore, peut prendre le sémaphore plus d'une fois. Options pour rendre la tâche qui les takes as DELETE_SAFE sont fournis par Mutex, ce qui signifie que la suppression de la tâche n'est pas possible lorsque le mutex est tenu.

alors qu'un sémaphore binaire peut être utilisé comme mutex, un mutex est un cas d'utilisation plus spécifique, en ce que seul le processus qui a verrouillé le mutex est censé le déverrouiller. Cette contrainte de propriété permet de fournir une protection contre:

• cas de dispersion Accidentelle
• Impasse Récursive
• L'Impasse De La Tâche De Mort

ces contraintes ne sont pas toujours présentes parce qu'elles dégrader la vitesse. Pendant le développement de votre code, vous pouvez activer ces contrôles Temporairement.

par exemple, vous pouvez activer l'attribut de vérification D'erreur dans votre mutex. Erreur vérification des Mutex retournez EDEADLK si vous essayez de verrouiller le même deux fois et EPERM si vous déverrouillez un mutex qui n'est pas le vôtre.

pthread_mutex_t mutex;
pthread_mutexattr_t attr;
pthread_mutexattr_init (&attr);
pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_ERRORCHECK_NP);
pthread_mutex_init (&mutex, &attr);

une fois initialisés, nous pouvons placer ces contrôles dans notre code comme ceci:

if(pthread_mutex_unlock(&mutex)==EPERM)
 printf("Unlock failed:Mutex not owned by this thread\n");

Mutex est utilisé pour protéger le code et les données sensibles, sémaphore est utilisé pour la synchronisation.Vous pouvez également avoir une utilisation pratique avec protéger le code sensible, mais il pourrait y avoir un risque que la libération de la protection par l'autre fil par l'opération V. Ainsi, la principale différence entre bi-sémaphore et mutex est la propriété.Par exemple, toilettes , Mutex est comme ça, on peut entrer dans les toilettes et verrouiller la porte, personne ne peut entrer jusqu'à l'homme de sortir, bi-sémaphore est comme que l'on peut entrer dans les toilettes et verrouiller la porte, mais quelqu'un d'autre pourrait entrer en demandant à l'administrateur pour ouvrir la porte, c'est ridicule.

la réponse peut dépendre de l'OS cible. Par exemple, au moins une implémentation RTOS que je connais permettra de multiples opérations séquentielles "get" contre un seul mutex OS, à condition qu'elles soient toutes dans le même contexte de thread. Les gets multiples doivent être remplacés par un nombre égal de puts avant qu'un autre thread ne soit autorisé à obtenir le mutex. cela diffère des sémaphores binaires, pour lesquels un seul get est autorisé à la fois, quel que soit le thread cadre.

l'idée derrière ce type de mutex est que vous protégez un objet en ne permettant qu'à un seul contexte de modifier les données à la fois. Même si le thread obtient le mutex et appelle ensuite une fonction qui modifie davantage l'objet (et obtient/met le mutex protecteur autour de ses propres opérations), les opérations devraient toujours être sûres parce qu'elles se passent toutes sous un seul thread.

{
    mutexGet();  // Other threads can no longer get the mutex.

    // Make changes to the protected object.
    // ...

    objectModify();  // Also gets/puts the mutex.  Only allowed from this thread context.

    // Make more changes to the protected object.
    // ...

    mutexPut();  // Finally allows other threads to get the mutex.
}

bien sûr, en utilisant ce fonction, vous devez être certain que tous les accès dans un seul thread sont vraiment en sécurité!

Je ne sais pas si cette approche est courante ou si elle s'applique à l'extérieur des systèmes que je connais. Pour un exemple de ce type de mutex, voir les RTOS ThreadX.

les mutex sont propriétaires, contrairement aux sémaphores. Bien que n'importe quel fil, dans le cadre d'un mutex, peut obtenir un mutex déverrouillé et verrouiller l'accès à la même section critique du code, seulement le fil qui a verrouillé un mutex devrait déverrouiller .

Mutex & Semaphore binaire est à la fois d'usage mais en réalité, ils sont différents. Dans le cas de mutex, le fil qui L'a verrouillé, seul celui-ci peut le déverrouiller. Si un autre fil vient le verrouiller, il attendra. Mais en cas de sémaphone, ce n'est pas le cas. Le sémaphore n'est pas attaché par un numéro d'identification du fil.

comme beaucoup de gens ici ont mentionné, un mutex est utilisé pour protéger un morceau de code critique (alias section critique.) Vous allez acquérir le mutex (verrouillage), entrer dans la section critique, et libérer mutex (déverrouillage) tous dans le même thread .

en utilisant un sémaphore, vous pouvez faire attendre un fil sur un sémaphore (dire fil A), jusqu'à ce qu'un autre fil (dire fil B)complète n'importe quelle tâche, et puis met le sémaphore pour fil a pour arrêter l'attente, et continuer sa tâche.

presque tout ce qui précède le dit correctement. Permettez-moi également d'essayer de clarifier si quelqu'un a encore un doute. Mutex -> utilisé pour la sérialisation Sémaphore-> synchronisation. But des deux sont différents, mais la même fonctionnalité pourrait être réalisée à travers les deux avec une programmation soignée. Exemple type - > producteur problème de consommation. valeur initiale de SemaVar = 0

Producteur Consommateur --- SemaWait () - > décrément SemaVar

produire des données

SemaSignal SemaVar ou SemaVar++ --->consommation débloque comme SemVar est 1 maintenant.

J'espère pouvoir clarifier.