Både semaforer och monitorer är synkroniseringsprimitiva som används i samtidig programmering för att hantera tillgång till delade resurser och förhindra rasförhållanden. Men de skiljer sig åt i sin struktur, verkställighet och hur de används. Här är en uppdelning av de viktigaste skillnaderna:
1. Struktur och implementering:
* Semaphores:
* Enkla heltalsvariabler: I sin kärna är semaforer heltalsvariabler som nås och modifieras med hjälp av atomoperationer.
* Två atomoperationer: De har vanligtvis två primära operationer:
* `vänta ()` (eller `p ()` eller `förvärva ()`):minskar semaforvärdet. Om värdet blir negativt blockerar processen/tråden tills semaforvärdet är större än eller lika med noll.
* `signal ()` (eller `v ()` eller `release ()`):Ökar semaforvärdet. Om det finns blockerade processer/trådar som väntar på semaforen är en av dem oblockerad.
* Ingen implicit dataförening: Semaphores binder inte i sig synkroniseringsmekanismen till specifika data. Du kan använda en semafor för att kontrollera åtkomst till alla delade resurser, men du måste hantera föreningen manuellt.
* monitorer:
* Strukturerad strategi: Monitorer är mer strukturerade programmeringskonstruktioner. De kapslar in:
* delade data: Variabler som representerar den delade resursen skyddas.
* Förfaranden/metoder: Operationerna som åtkomst och modifierar delade uppgifter. Dessa är de enda rutinerna som får direkt komma åt de delade uppgifterna.
* Skickvariabler: (VIKTIGT!) Särskilda variabler som används för signalering och väntan inom monitorn.
* Explicit ömsesidig uteslutning: Monitorer ger implicit ömsesidig uteslutning. Endast en tråd/process kan vara aktiv * inuti * monitorn vid en viss tidpunkt. Denna ömsesidiga uteslutning verkställs automatiskt av själva skärmen.
2. Verkställighet av ömsesidig uteslutning:
* Semaphores:
* manuell verkställighet: Semaphores förlitar sig på programmerare för att korrekt använda `vänta ()` och `signal ()` operationer kring kritiska avsnitt. Det är upp till programmeraren att säkerställa att ömsesidig uteslutning upprätthålls korrekt. Fel kan enkelt introduceras. Att till exempel glömma en "signal ()" kan leda till dödläge. Att placera `vänta ()` eller `signal ()` utanför det avsedda kritiska avsnittet kan orsaka samtidighetsproblem.
* fel benägna: Denna manuell verkställighet är benägen att fel. Det är lätt att göra misstag som bryter ömsesidig uteslutning eller orsakar dödlås.
* monitorer:
* Implicit Enforcement: Monitorer verkställer ömsesidig uteslutning *Implicit *. Språket/systemet säkerställer att endast en tråd kan vara aktiv inuti monitorn åt gången. Detta gör det lättare att resonera om och mindre benägna för fel. Kompilatorn eller runtime -systemet hanterar låsning och låsning.
3. Tillståndssynkronisering (väntar och signalering):
* Semaphores:
* Allmänt, men mindre strukturerat för att vänta på tillstånd: Semaphores * kan * användas för tillståndssynkronisering (t.ex. väntar på att en resurs ska bli tillgänglig). Men det är lite besvärligt. Du behöver vanligtvis separata semaforer för ömsesidig uteslutning och för signalförhållanden, vilket gör koden mer komplex och benägen att fel. Du kan använda räknings -semaforer för att ange hur många av en resurs som finns tillgängliga.
* monitorer:
* Skickvariabler: Monitorer använder * tillståndsvariabler * specifikt för tillståndssynkronisering. Dessa ger operationer som:
* `Vänta (skick)`:Den samtalstråden släpper monitorlåset och väntar på det angivna `villkoret '. Tråden placeras i en kö som är associerad med det tillståndsvariabeln. Monitorlåset släpps så att andra trådar kan komma in i monitorn.
* `Signal (tillstånd)`:En tråd som väntar på det angivna `tillståndet 'väcks. Den signalerade tråden förvärvar monitorlåset igen.
* `Broadcast (villkor)` (eller `signalAll (villkor)`):väcker alla trådar som väntar på det angivna `villkoret '.
* Förbättrad struktur: Skickvariabler är nära bundna till monitorn och dess delade data, vilket gör det lättare att förstå och resonera om tillståndssynkronisering inom monitorn.
4. Ägare och ansvar:
* Semaphores:
* Inget tydligt ägande: Varje tråd kan `vänta ()` eller `signal ()` på en semafor. Det finns inget begrepp att "äga" en semafor.
* monitorer:
* Clear Ownership: Trådar måste ange monitorn (implicit förvärva monitorns lås) innan de delade variabler för delade data eller signalering. Detta verkställer en tydlig ägarmodell.
5. Reentrance:
* Semaphores:
* Inget inneboende begrepp om återinförande: Semaphores vet inte om tråden som ringer `vänta ()` eller `signal ()` redan har semaforen. Att använda en semaphore reentrant (t.ex. samma tråd förvärvar semaforen flera gånger utan att släppa den) kan lätt leda till dödläge.
* monitorer:
* Generellt icke-reentrant: Monitorer är vanligtvis utformade för att vara *icke-reentrant *. En tråd som redan håller monitorlåset kan inte gå in i monitorn igen. Detta förenklar resonemanget om programmets tillstånd men kan ibland kräva omstruktureringskod. Vissa övervakningsimplementeringar stöder återinförande, men det är mindre vanligt.
Sammanfattningsvis:
| Funktion | Semaphores | Bildskärmar |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Struktur | Enkla heltalsvariabler | Strukturerad konstruktion med data, procedurer och tillståndsvariabler |
| Ömsesidig uteslutning | Manual (programmeraransvar) | Implicit (verkställs av själva skärmen) |
| Tillståndssynkronisering | Kan användas, men mindre strukturerade | Explicit med tillståndsvariabler (vänta, signal, sändning) |
| Fel benägen | Mer fel benägna på grund av manuell hantering | Mindre felbenägna på grund av implicit verkställighet |
| Ägande | Inget tydligt ägande | Clear Ownership (tråd måste komma in i monitorn) |
| Reentrance | Vanligtvis inte betraktas som | Generellt icke-reentrant |
När ska man använda vilken:
* Semaphores: Även om det fortfarande är värdefullt, ses semaforer ofta som en primitiv på lägre nivå. De är användbara när en enkel räknemekanism behövs, eller när synkroniseringskraven är mycket grundläggande. De är också till hjälp i system där bildskärmar inte stöds naturligt.
* monitorer: Monitorer föredras när de hanterar mer komplexa synkroniseringsscenarier. Deras strukturerade tillvägagångssätt, implicit ömsesidig uteslutning och tillståndsvariabler gör det lättare att skriva korrekt och underhållbar samtidig kod. Monitorer är väl lämpade för att skydda delade datastrukturer och implementera synkroniseringsmönster. Många moderna programmeringsspråk ger inbyggt stöd för monitorer eller liknande konstruktioner (t.ex. Java's "synkroniserade" nyckelord och "vänta ()", "meddela ()", "notifyAll ()" metoder, eller pythons "gängor" och "tråd. Condition").
Exempel (konceptuellt - inte specifikt språk):
Semaphore Exempel (konceptuell):
`` `
Semaphore mutex =1; // binär semafor för ömsesidig uteslutning
Semaphore ResourceAvailAble =0; // Räkna semafor för tillgängliga resurser
// tråd 1 (producent)
vänta (mutex);
// åtkomst och modifiera delad resurs
// Lägg till resurs
signal (mutex);
signal (ResourceAvailble); // signalera att en resurs nu är tillgänglig
// tråd 2 (konsument)
Vänta (resursavgänglig); // vänta på att en resurs blir tillgänglig
vänta (mutex);
// åtkomst och modifiera delad resurs
// Konsumera resurs
signal (mutex);
`` `
Monitor Exempel (konceptuellt):
`` `
Övervaka myMonitor {
delade data:...;
villkor resursavgänglig;
metod accessResource () {
// förvärva implicit monitorlås
medan (resurs inte är tillgänglig) {
Vänta (resursavgänglig); // Release Monitor Lock, vänta på tillstånd
}
// åtkomst och modifiera delade data
// ...
signal (ResourceAvailble); // Signalvänttråd
// frigör implicit monitorlåset när metoden returneras
}
metod addResource () {
// förvärva implicit monitorlås
// Lägg till resurs till delad data
signal (ResourceAvailble); // Signalvänttråd
// släpp implicit monitorlåset
}
}
`` `
I bildskärmsexemplet hanteras den ömsesidiga uteslutningen automatiskt av monitorn, vilket gör det mindre benäget att fel. Skickvariabler ger ett mer strukturerat sätt att hantera väntan och signalering jämfört med att använda semaforer direkt för detta ändamål.
