Verschil tussen binaire semafoor en mutex

Is er enig verschil tussen een binaire semafoor en mutex of zijn ze in wezen hetzelfde?

Antwoord 1, autoriteit 100%

Ze zijn NIEThetzelfde. Ze worden voor verschillende doeleinden gebruikt!
Hoewel beide typen semaforen een volledige/lege status hebben en dezelfde API gebruiken, is hun gebruik heel anders.

Semaforen voor wederzijdse uitsluiting
Wederzijdse uitsluiting semaforen worden gebruikt om gedeelde bronnen (datastructuur, bestand, enz..) te beschermen.

Een Mutex-semafoor is ‘eigendom’ van de taak die ervoor zorgt. Als Taak B probeert een mutex te geven die momenteel in het bezit is van Taak A, zal de oproep van Taak B een fout retourneren en mislukken.

Mutexen gebruiken altijd de volgende volgorde:

- SemTake
 - Kritieke sectie
 - SemGive

Hier is een eenvoudig voorbeeld:

Draad A Draad B
  Neem Mutex
   toegangsgegevens
   ... Neem Mutex <== Zal blokkeren
   ...
  Geef Mutex toegangsgegevens <== Deblokkeren
                 ...
                Geef Mutex

Binaire semafoor
Binaire semafoor behandelt een totaal andere vraag:

• Taak B wacht totdat er iets gebeurt (bijvoorbeeld een sensor die wordt geactiveerd).
• Sensor Trips en een Interrupt Service Routine worden uitgevoerd. Het moet een taak van de reis melden.
• Taak B moet worden uitgevoerd en passende acties ondernemen voor de sensortrip. Ga dan terug naar wachten.

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

Merk op dat met een binaire semafoor het OK is dat B de semafoor neemt en A om deze te geven.
Nogmaals, een binaire semafoor beschermt een bron NIET tegen toegang. De handeling van het geven en nemen van een semafoor zijn fundamenteel ontkoppeld.
Het heeft meestal weinig zin om dezelfde taak op dezelfde binaire semafoor te geven en te nemen.

Antwoord 2, autoriteit 65%

• Een mutexkan alleen worden vrijgegeven door de thread die deze heeft verkregen.
• Een binaire semafoorkan door elke thread(of proces) worden gesignaleerd.

Semaforen zijn dus meer geschikt voor sommige synchronisatieproblemen, zoals producent-consument.

In Windows lijken binaire semaforen meer op gebeurtenisobjecten dan op mutexen.

Antwoord 3, autoriteit 62%

Het Toilet-voorbeeldis een plezierige analogie:

Mutex:

Is een sleutel tot een toilet. Een persoon kan
de sleutel hebben – het toilet bezetten – bij
de tijd. Wanneer klaar, de persoon
geeft (bevrijdt) de sleutel tot de volgende
persoon in de wachtrij.

Officieel: “Mutexen zijn meestal
gebruikt om toegang tot een sectie te serialiseren
van herintredercode die niet kan worden
gelijktijdig uitgevoerd door meer dan één
draad. Een mutex-object staat slechts één toe
draad in een gecontroleerde sectie,
forceren van andere threads die proberen om
toegang krijgen tot dat gedeelte om te wachten
totdat de eerste thread is afgesloten van
die sectie.” Ref: Symbian Developer
Bibliotheek

(Een mutex is eigenlijk een semafoor met
waarde 1.)

Semaphore:

Is het aantal gratis identieke toiletten
sleutels. Voorbeeld, stel dat we er vier hebben
toiletten met identieke sloten en sleutels.
De semafoortelling – de telling van
toetsen – is ingesteld op 4 aan het begin (alle
vier toiletten zijn gratis), dan is de telling
waarde wordt verlaagd zoals mensen zijn
binnenkomen. Als alle toiletten vol zijn,
d.w.z. er zijn geen vrije sleutels meer, de
semafoor telling is 0. Nu, wanneer eq.
één persoon verlaat het toilet,
semafoor wordt verhoogd tot 1 (één gratis
sleutel), en gegeven aan de volgende persoon in
de wachtrij.

Officieel: “Een semafoor beperkt de
aantal gelijktijdige gebruikers van a
gedeelde bron tot een maximum
nummer. Discussies kunnen toegang vragen tot:
de resource (het verlagen van de
semafoor), en kunnen signaleren dat ze
klaar bent met het gebruik van de bron
(verhogen van de semafoor).” Ref:
Symbian-ontwikkelaarsbibliotheek

Antwoord 4, autoriteit 22%

Leuke artikelen over het onderwerp:

• MUTEX VS . SEMAPHOREN – DEEL 1: SEMAPHOREN
• MUTEX VS. SEMAPHORES – DEEL 2: DE MUTEX
• MUTEX VS. SEMAPHORES – DEEL 3 (LAATSTE DEEL): PROBLEMEN VAN WEDERZIJDSE UITSLUITING

Uit deel 2:

De mutex is vergelijkbaar met de principes
van de binaire semafoor met één
significant verschil: het principe
van eigendom. Eigendom is simpel
concept dat wanneer een taak wordt vergrendeld
(verkrijgt) een mutex die alleen deze kan ontgrendelen
(geef het vrij. Als een taak probeert
ontgrendel een mutex die hij niet heeft vergrendeld (dus
bezit niet) dan een foutconditie
wordt aangetroffen en, belangrijker nog,
de mutex is niet ontgrendeld. Als de
wederzijdse uitsluiting object heeft geen
eigendom dan, ongeacht wat het is
wordt genoemd, is het geen mutex.

Antwoord 5, autoriteit 15%

Aangezien geen van de bovenstaande antwoorden de verwarring oplost, is hier een die mijn verwarring heeft weggenomen.

Strikt genomen, een mutex is een vergrendelingsmechanismedat wordt gebruikt om
toegang tot een bron synchroniseren. Slechts één taak (kan een thread zijn of
proces gebaseerd op OS-abstractie) kan de mutex verkrijgen. Het betekent daar
zal eigendom zijn geassocieerd met mutex, en alleen de eigenaar kan
ontgrendel het slot (mutex).

Semaphore is een signaalmechanisme(‘Ik ben klaar, je kunt doorgaan’-signaal). Als u bijvoorbeeld naar nummers luistert (neem aan dat
één taak) op je mobiel en tegelijkertijd belde je vriend je,
een interrupt wordt geactiveerd waarop een interruptserviceroutine
(ISR) zal de oproepverwerkingstaak signaleren om wakker te worden.

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

Antwoord 6, autoriteit 6%

Hun synchronisatiesemantiek is heel anders:

• mutexen maken serialisatie van toegang tot een bepaalde bron mogelijk, dwz meerdere threads wachten op een slot, één voor één en zoals eerder gezegd, de thread bezithet slot totdat het klaar is: alleen deze specifieke thread kan deze ontgrendelen.
• een binaire semafoor is een teller met waarde 0 en 1: een taak die erop blokkeert totdat elketaak een sem_post doet. De semafoor adverteert dat een bron beschikbaar is, en het biedt het mechanisme om te wachten tot het wordt gesignaleerd als beschikbaar.

Als zodanig kan men een mutex zien als een token dat van taak naar taak wordt doorgegeven en een semafoor als verkeersrood licht (het signaaliemand dat het kan doorgaan).

Antwoord 7, autoriteit 4%

Op theoretisch niveau zijn ze semantisch niet anders. U kunt een mutex implementeren met behulp van semaforen of vice versa (zie hiervoor een voorbeeld). In de praktijk zijn de implementaties anders en bieden ze net iets andere diensten aan.

Het praktische verschil (in termen van de systeemdiensten eromheen) is dat de implementatie van een mutex is gericht op een lichter synchronisatiemechanisme. In orakeltaal staan mutexen bekend als grendelsen zijn semaforen bekend terwijl wacht.

Op het laagste niveau gebruiken ze een soort van atomaire test en setmechanisme. Dit leest de huidige waarde van een geheugenlocatie, berekent een soort voorwaardelijk en schrijft een waarde op die locatie uit in een enkele instructie die kan niet worden onderbroken. Dit betekent dat u een mutex kunt aanschaffen en kunt testen of iemand anders deze voor u heeft gehad.

Een typische mutex-implementatie heeft een proces of thread die de test-en-set-instructie uitvoert en evalueert of iets anders de mutex heeft ingesteld. Een belangrijk punt hierbij is dat er geen interactie is met de planner, dus we hebben geen idee (en maakt niet uit) wie het slot heeft ingesteld. Dan geven we ofwel onze tijdschijf op en proberen het opnieuw wanneer de taak opnieuw wordt gepland, of we voeren een spin- slot. Een spin-lock is een algoritme zoals:

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.

Wanneer we klaar zijn met het uitvoeren van onze beschermde code (bekend als een kritieke sectie ) We Stel de MUTEX-waarde in op nul of wat betekent wel ‘duidelijk’. Als meerdere taken proberen de MUTEX te verwerven, wordt de volgende taak die toevallig wordt gepland nadat de Mutex wordt vrijgegeven, toegang krijgt tot de bron. Meestal zou u MUTEXES gebruiken om een ​​gesynchroniseerde bron te besturen waar exclusieve toegang alleen nodig is voor zeer korte perioden, normaal gesproken om een ​​update aan een gedeelde data-structuur te maken.

Een semafoor is een gesynchroniseerde data-structuur (meestal met behulp van een mutex) met een telling en sommige systeemoproepwikkelaars die met de planner in een beetje meer diepte communiceren dan de Mutex-bibliotheken. Semaforen worden verhoogd en verlaagd en gebruikt voor blok taken totdat er iets anders klaar is. Zie producent / consumentenprobleem voor een eenvoudig voorbeeld hiervan. Semaforen worden geïnitialiseerd in een of andere waarde – een binaire semafoor is slechts een speciaal geval waarin de semafoor wordt geïnitialiseerd naar 1. Posten bij een semafoor heeft het effect van het waken van een wachtproces.

Een eenvoudig semafoor-algoritme ziet eruit als:

(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.

In het geval van een binaire semafoor is het belangrijkste praktische verschil tussen de twee de aard van de systeemdiensten die de feitelijke gegevensstructuur omringen.

EDIT: Zoals evan terecht heeft opgemerkt, zullen spinlocks een enkele processormachine vertragen. Je zou alleen een spinlock gebruiken op een doos met meerdere processors, omdat op een enkele processor het proces dat de mutex vasthoudt, het nooit zal resetten terwijl een andere taak wordt uitgevoerd. Spinlocks zijn alleen nuttig bij architecturen met meerdere processors.

Antwoord 8, autoriteit 3%

Hoewel mutex & semaforen worden gebruikt als synchronisatieprimitieven, er is een groot verschil tussen hen.
In het geval van mutex kan alleen de thread die de mutex heeft vergrendeld of verkregen, deze ontgrendelen.
In het geval van een semafoor kan een draad die op een semafoor wacht, worden gesignaleerd door een andere draad.
Sommige besturingssystemen ondersteunen het gebruik van mutex & semaforen tussen proces. Gebruik wordt meestal gemaakt in het gedeelde geheugen.

Antwoord 9, autoriteit 2%

Mutex: Stel dat we een kritieke sectie hebben die thread T1 wil openen, dan volgt het onderstaande stappen.
T1:

1. Vergrendelen
2. Gebruik kritieke sectie
3. Ontgrendelen

Binaire semafoor: het werkt op basis van signalering wachten en signaal.
wacht(en) verlaag de “s”-waarde met één, meestal wordt de “s”-waarde geïnitialiseerd met de waarde “1”,
signaal(en) verhoogt de “s”-waarde met één. als de waarde “s” 1 is, betekent dat niemand de kritieke sectie gebruikt, als de waarde 0 is, betekent de kritieke sectie in gebruik.
stel dat thread T2 kritieke sectie gebruikt, dan volgt het onderstaande stappen.
T2 :

1. wacht(en)//aanvankelijk is de waarde één na het aanroepen van wacht, de waarde is met één afgenomen, d.w.z. 0
2. Gebruik kritieke sectie
3. signaal(en) // nu is de waarde verhoogd en wordt het 1

Het belangrijkste verschil tussen Mutex en binaire semafoor is in Mutext. Als een thread de kritieke sectie vergrendelt, moet deze de kritieke sectie ontgrendelen. functie dan wordt de waarde van s “0” en niemand heeft er toegang toe totdat de waarde van “s” 1 wordt, maar stel dat een andere thread signaal(en) oproept, dan wordt de waarde van “s” 1 en het staat een andere functie toe om kritieke sectie te gebruiken .
vandaar dat in binaire semafoor thread geen eigendom heeft.

Antwoord 10, autoriteit 2%

In Windows zijn er twee verschillen tussen mutexen en binaire semaforen:

1. Een mutex kan alleen worden vrijgegeven door de thread die eigendom heeft, d.w.z. de thread die eerder de Wait-functie aanriep (of die eigendom werd bij het maken ervan). Een semafoor kan door elke thread worden vrijgegeven.

2. Een thread kan herhaaldelijk een wachtfunctie oproepen op een mutex zonder te blokkeren. Als je echter twee keer een wachtfunctie aanroept op een binaire semafoor zonder de semafoor ertussen los te laten, blokkeert de thread.

Antwoord 11

U gebruikt duidelijk mutex om gegevens in de ene thread te vergrendelen die tegelijkertijd door een andere thread worden geopend. Stel dat u zojuist lock()hebt aangeroepen en bezig bent met het openen van gegevens. Dit betekent dat je niet verwacht dat een andere thread (of een ander exemplaar van dezelfde thread-code) toegang krijgt tot dezelfde gegevens die zijn vergrendeld door dezelfde mutex. Dat wil zeggen, als het dezelfde thread-code is die wordt uitgevoerd op een andere thread-instantie, de lock raakt, dan zou de lock()de controlestroom daar moeten blokkeren. Dit is van toepassing op een thread die een andere thread-code gebruikt, die ook toegang heeft tot dezelfde gegevens en die ook wordt vergrendeld door dezelfde mutex. In dit geval bent u nog steeds bezig met het openen van de gegevens en kunt u bijvoorbeeld nog 15 seconden nodig hebben om de mutex-ontgrendeling te bereiken (zodat de andere thread die in mutex-vergrendeling wordt geblokkeerd, de blokkering zou deblokkeren en de besturing in staat zou stellen om toegang tot de gegevens). Sta je koste wat kost toe dat nog een andere thread dezelfde mutex ontgrendelt en op zijn beurt de thread die al wacht (blokkeert) in de mutex-vergrendeling deblokkeren en toegang geeft tot de gegevens? Ik hoop dat je begrijpt wat ik hier zeg?
Volgens, overeengekomen universele definitie!,

• met “mutex” kan dit niet gebeuren. Geen andere thread kan het slot ontgrendelen
  in je topic
• met “binaire-semafoor” kan dit gebeuren. Elke andere thread kan ontgrendelen
  het slotje in je topic

Dus, als je erg kieskeurig bent over het gebruik van binaire semafoor in plaats van mutex, dan moet je heel voorzichtig zijn bij het “scooppen” van de sloten en ontgrendelingen. Ik bedoel dat elke controlestroom die elke vergrendeling raakt, een ontgrendelingsoproep moet raken, ook zou er geen “eerste ontgrendeling” moeten zijn, maar zou altijd “eerste vergrendeling” moeten zijn.

Antwoord 12

Mutex wordt gebruikt voor “Vergrendelingsmechanismen”. één proces tegelijk kan een gedeelde bron gebruiken

terwijl

Semaforen worden gebruikt voor “Signaleringsmechanismen”
zoals “Ik ben klaar, kan nu doorgaan”

Antwoord 13

Mythe:

In een paar artikelen staat dat “binaire semafoor en mutex hetzelfde zijn” of “Semaphore met waarde 1 is mutex”, maar het fundamentele verschil is dat Mutex alleen kan worden vrijgegeven door een thread die het heeft verkregen, terwijl u de semafoor van een ander kunt signaleren draad

Belangrijkste punten:

•Een thread kan meer dan één lock krijgen (Mutex).

•Een mutex kan alleen meer dan één keer worden vergrendeld als het een recursieve mutex is, hier moeten vergrendelen en ontgrendelen voor mutex hetzelfde zijn

•Als een thread die al een mutex had vergrendeld, de mutex opnieuw probeert te vergrendelen, komt deze op de wachtlijst van die mutex, wat resulteert in een deadlock.

•Binaire semafoor en mutex zijn vergelijkbaar, maar niet hetzelfde.

•Mutex is een kostbare operatie vanwege de bijbehorende beveiligingsprotocollen.

•Hoofddoel van mutex is atomaire toegang te verkrijgen of resource vast te zetten

Antwoord 14

Gewijzigde vraag is – Wat is het verschil tussen een mutex en een “binaire” semafoor in “Linux”?

ANS: volgende zijn de verschillen –
i) Scope – De reikwijdte van Mutex bevindt zich binnen een procesadresruimte die het heeft gemaakt en wordt gebruikt voor synchronisatie van draden. Overwegende dat semafoor kan worden gebruikt over de procesruimte en kan het daarom worden gebruikt voor interprocessesynchronisatie.

ii) mutex is lichtgewicht en sneller dan semafoor. FUTEX is nog sneller.

III) Mutex kan met behulp van voorwaarde met voorwaarde worden verworven met dezelfde thread die het hetzelfde aantal keren zou moeten vrijgeven. Andere thread die proberen te verwerven, blokkeren. Overwegende dat in geval van semafoor als hetzelfde proces het opnieuw probeert te verwerven, blokkeert het, omdat deze slechts één keer kan worden verkregen.

15

diff tussen binaire semafoor en mutex:
EIGENDOM:
semaforen kunnen worden gesignaleerd (gepost), zelfs van een niet-huidige eigenaar. Het betekent dat u eenvoudigweg van een andere thread kunt plaatsen, hoewel u niet de eigenaar bent.

Semafoor is een openbaar bezit in proces, het kan eenvoudig worden geplaatst door een niet-eigenaar-draad.
Markeer dit verschil in gedurfde letters, het betekent veel.

16

Mutex Werk op het blokkeren van kritische regio, maar semafoor werk op telling.

17

http://www.geeksforGeeks.org/Archives/9102 bespreekt in details. < / p>

Mutexis het vergrendelingsmechanisme dat wordt gebruikt om de toegang tot een bron te synchroniseren.
Semaphoreis signaleringsmechanisme.

het is tot aan de programmeur als hij / zij binaire semafoor wil gebruiken in plaats van Mutex.

18

Behalve het feit dat mutexen een eigenaar hebben, kunnen de twee objecten worden geoptimaliseerd voor verschillend gebruik. Mutexen zijn ontworpen om slechts voor een korte tijd te worden vastgehouden; het schenden hiervan kan leiden tot slechte prestaties en oneerlijke planning. Een lopende thread kan bijvoorbeeld toestemming krijgen om een mutex te verwerven, ook al is er al een andere thread op geblokkeerd. Semaforen kunnen meer eerlijkheid bieden, of eerlijkheid kan worden afgedwongen met behulp van verschillende conditievariabelen.

Antwoord 19

In Windows is het verschil als volgt.
MUTEX:proces dat wachtsuccesvol uitvoert, moet een signaaluitvoeren en vice versa. BINAIRE SEMAPHORES:verschillende processen kunnen een wacht– of signaal-bewerking uitvoeren op een semafoor.

Antwoord 20

Terwijl een binaire semafoor als mutex kan worden gebruikt, is een mutex een meer specifieke use-case, in die zin dat alleen het proces dat de mutex heeft vergrendeld, deze moet ontgrendelen. Deze eigendomsbeperking maakt het mogelijk om bescherming te bieden tegen:

• Onbedoelde vrijlating
• Recursieve impasse
• Taak Death Deadlock

Deze beperkingen zijn niet altijd aanwezig omdat ze de snelheid verminderen. Tijdens de ontwikkeling van uw code kunt u deze controles tijdelijk inschakelen.

bijv. u kunt het foutcontrolekenmerk inschakelen in uw mutex. Fout bij het controleren van mutexen retourneert EDEADLKals u dezelfde tweemaal probeert te vergrendelen en EPERMals u een mutex ontgrendelt die niet van u is.

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);

Eenmaal geïnitialiseerd kunnen we deze controles als volgt in onze code plaatsen:

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

Antwoord 21

Het concept was me duidelijk nadat ik bovenstaande berichten had doorgenomen. Maar er waren enkele slepende vragen. Dus schreef ik dit kleine stukje code.

Als we een semafoor proberen te geven zonder hem te nemen, gaat hij door. Maar als je een mutex probeert te geven zonder het te nemen, mislukt het. Ik heb dit getest op een Windows-platform. Schakel USE_MUTEX in om dezelfde code uit te voeren met een 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;
}

Alleen al het feit dat semafoor je laat signaleren “het is gedaan met behulp van een bron”, hoewel het nooit de bron heeft gehad, doet me denken dat er een zeer losse koppeling is tussen bezit en signalering in het geval van semaforen.

Antwoord 22

Mutex wordt gebruikt om de gevoelige code en gegevens te beschermen, het semafoor wordt gebruikt om te synchroniseren. U kunt ook praktisch gebruik hebben met de bescherming van de gevoelige code, maar er kan een risico zijn dat de bescherming door de andere draad door Operatie V. Dus het belangrijkste verschil tussen BI-Semafoor en Mutex is de eigendom. Voor instantie door toilet, is Mutex zo dat men het toilet kan betreden en de deur vergrendelen, niemand anders kan binnengaan totdat de man eruit komt, Men kan het toilet binnendringen en de deur vergrendelen, maar iemand anders zou kunnen binnenkomen door de beheerder te vragen om de deur te openen, het is belachelijk.

23

Mutex

Mutexes worden meestal gebruikt om toegang te nemen tot een deel van de nieuwkomerscode die niet gelijktijdig door meer dan één draad kan worden uitgevoerd. Een MUTEX-object geeft slechts één draad in een gecontroleerde sectie, waardoor andere threads die proberen toegang te krijgen tot die sectie om te wachten totdat de eerste thread is verlaten van die sectie. Het gebruik van een MUTEX is om een ​​gedeelde bron te beschermen onbedoelde bijwerking. Elke twee RTO’s-taken die op verschillende prioriteiten opereren en coördineren via een Mutex, creëren de mogelijkheid voor prioritaire inversie . Mutex werkt in Gebruikersruimte .

semafoor

Semaphore is een signaleringsmechanisme. Semaphore beperkt het aantal gelijktijdige gebruikers van een gedeelde bron tot een maximum aantal. Threads kunnen toegang tot de bron vragen (de semafoor verlagen) en kunnen aangeven dat ze klaar zijn met het gebruik van de bron (de semafoor verhogen). Het geeft een aantal threads toegang tot gedeelde bronnen. Het juiste gebruik van een semafoor is voor het signaleren van de ene taak naar de andere. Semaphores kunnen ook worden gebruikt om te signaleren vanuit een interrupt-serviceroutine(ISR) naar een taak. Het signaleren van een semafoor is een niet-blokkerend RTOS-gedrag en dus ISR-veilig. Omdat deze techniek de foutgevoelige noodzaak elimineert om interrupts op taakniveau uit te schakelen. Dit werkt in kernelruimte.

Antwoord 24

Ik denk dat de meeste antwoorden hier verwarrend waren, vooral degenen die zeiden dat mutex alleen kan worden vrijgegeven door het proces dat het vasthoudt, maar semafoor kan door elk proces worden gesignaleerd. De bovenstaande regel is nogal vaag in termen van semafoor. Om te begrijpen moeten we weten dat er twee soorten semafoor zijn, de ene wordt de telsemafoor genoemd en de andere wordt een binaire semafoor genoemd. Bij het tellen behandelt de semafoor toegang tot n aantal bronnen waar n kan worden gedefinieerd vóór het gebruik. Elke semafoor heeft een count-variabele, die de telling van het aantal in gebruik zijnde bronnen bijhoudt, in eerste instantie is deze ingesteld op n. Elk proces dat een resource wil gebruiken, voert een wait()-bewerking uit op de semafoor (waardoor de telling wordt verlaagd). Wanneer een proces een resource vrijgeeft, voert het een release()-bewerking uit (de telling wordt verhoogd). Wanneer de telling 0 wordt, worden alle middelen gebruikt. Daarna wacht het proces tot de telling meer dan 0 wordt. Nu is hier de vangst alleen het proces dat de bron bevat kan de telling verhogen geen ander proces kan de telling verhogen alleen de processen die een bron bevatten kunnen de telling en het proces verhogen wachten op de semafoor controleert opnieuw en wanneer het de beschikbare bron ziet, verlaagt het de telling weer. Dus in termen van binaire semafoor kan alleen het proces dat de semafoor vasthoudt de telling verhogen, en de telling blijft nul totdat het stopt met het gebruik van de semafoor en de telling verhoogt en andere processen de kans krijgen om toegang te krijgen tot de semafoor.

Het belangrijkste verschil tussen binaire semafoor en mutex is dat semafoor een signaleringsmechanisme is en mutex een vergrendelingsmechanisme, maar binaire semafoor lijkt te functioneren als mutex die verwarring schept, maar beide zijn verschillende concepten die geschikt zijn voor verschillende soorten werk.

Antwoord 25

Het antwoord kan afhangen van het doel-besturingssysteem. Bijvoorbeeld, ten minste één RTOS-implementatie waarmee ik bekend ben, zal meerdere sequentiële “krijgen” -activiteiten tegen een enkele OS Mutex, zolang ze allemaal van binnen dezelfde draadcontext zijn. De meervoudige krijgt moeten worden vervangen door een gelijk aantal putjes voordat een andere thread de Mutex mag krijgen. Dit verschilt van binaire semaforen, waarvoor slechts één single krijgt per keer toegestaan, ongeacht draadcontents.

Het idee achter dit type MUTEX is dat u een object beschermt door alleen een enkele context toe te staan ​​om de gegevens tegelijk te wijzigen. Zelfs als de draad de MUTEX krijgt en vervolgens een functie oproepen die het object verdere wijzigt (en de beschermer van Mutex rond zijn eigen operaties krijgt), moeten de bewerkingen nog steeds veilig zijn omdat ze allemaal onder een enkele draad gebeuren.

{
    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.
}

Natuurlijk, wanneer u deze functie gebruikt, moet u er zeker van zijn dat alle toegang binnen een enkele thread echt veilig zijn!

Ik weet niet zeker hoe vaak deze benadering is, of dat het van toepassing is op buiten de systemen waarmee ik bekend ben. Zie de Threadx RTOS

voor een voorbeeld van dit soort Mutex.

Antwoord 26

Beste oplossing

Het enige verschil is

1.Mutex -> lock en unlock zijn eigendom van een thread die de mutex vergrendelt.

2.Semaphore -> Geen eigendom, d.w.z.; als een thread semwait(s) aanroept, kan elke andere thread sempost(s) aanroepen om het slot te verwijderen.

Antwoord 27

MUTEX

Tot voor kort was het enige slaapslot in de kernel de semafoor. De meeste gebruikers van semaforen startten een semafoor met een telling van één en behandelden ze als een wederzijdse uitsluitingsvergrendeling – een slapende versie van de spin-lock. Helaas zijn semaforen nogal generiek en leggen ze geen gebruiksbeperkingen op. Dit maakt ze nuttig voor het beheren van exclusieve toegang in obscure situaties, zoals gecompliceerde dansen tussen de kernel en de gebruikersruimte. Maar het betekent ook dat eenvoudiger vergrendelen moeilijker te doen is, en het gebrek aan afgedwongen regels maakt elke vorm van geautomatiseerde foutopsporing of het afdwingen van beperkingen onmogelijk. Op zoek naar een eenvoudiger slaapslot, introduceerden de kernelontwikkelaars de mutex. Ja, zoals je nu gewend bent, is dat een verwarrende naam. Laten we het verduidelijken. De term “mutex” is een generieke naam om te verwijzen naar elk slaapslot dat wederzijdse uitsluiting afdwingt, zoals een semafoor met een gebruikstelling van één. In recente Linux-kernels is het eigennaamwoord “mutex” nu ook een specifiek type slaapslot dat wederzijdse uitsluiting implementeert. Dat wil zeggen, een mutex is een mutex.

De eenvoud en efficiëntie van de mutex komen voort uit de extra beperkingen die het zijn gebruikers oplegt naast wat de semafoor vereist. In tegenstelling tot een semafoor, die het meest elementaire gedrag implementeert in overeenstemming met het oorspronkelijke ontwerp van Dijkstra, heeft de mutex een striktere, smallere use case:
n Slechts één taak kan de mutex tegelijk bevatten. Dat wil zeggen, de gebruikstelling op een mutex is altijd één.

1. Wie een mutex heeft vergrendeld, moet hem ontgrendelen. Dat wil zeggen, u kunt een mutex niet in één vergrendelen
   context en ontgrendel het vervolgens in een andere. Dit betekent dat de mutex niet geschikt is voor meer gecompliceerde synchronisaties tussen kernel en gebruikersruimte. De meeste gebruiksgevallen,
   vergrendel en ontgrendel echter netjes vanuit dezelfde context.
2. Recursieve vergrendelingen en ontgrendelingen zijn niet toegestaan. Dat wil zeggen, u kunt dezelfde mutex niet recursief verkrijgen en u kunt een ontgrendelde mutex niet ontgrendelen.
3. Een proces kan niet afsluiten terwijl je een mutex vasthoudt.
4. Een mutex kan niet worden verkregen door een interrupt-handler of onderste helft, zelfs niet met
   mutex_trylock().
5. Een mutex kan alleen worden beheerd via de officiële API: deze moet worden geïnitialiseerd via de methoden die in deze sectie worden beschreven en kan niet worden gekopieerd, handmatig worden geïnitialiseerd of opnieuw worden geïnitialiseerd.

[1] Linux-kernelontwikkeling, derde editie Robert Love