| Zowel semaforen als monitoren zijn synchronisatieprimitieven die worden gebruikt bij gelijktijdig programmeren om de toegang tot gedeelde bronnen te beheren en race-omstandigheden te voorkomen. Ze verschillen echter qua structuur, handhaving en manier waarop ze worden gebruikt. Hier volgt een overzicht van de belangrijkste verschillen:
1. Structuur en implementatie:
* Semaforen:
* Eenvoudige gehele variabelen: In de kern zijn semaforen integervariabelen die toegankelijk zijn en aangepast kunnen worden met behulp van atomaire bewerkingen.
* Twee atomaire operaties: Ze hebben doorgaans twee primaire bewerkingen:
* `wait()` (of `P()` of `acquire()`):Verlaagt de semafoorwaarde. Als de waarde negatief wordt, blokkeert het proces/thread totdat de semafoorwaarde groter is dan of gelijk is aan nul.
* `signal()` (of `V()` of `release()`):Verhoogt de semafoorwaarde. Als er geblokkeerde processen/threads op de semafoor wachten, wordt een daarvan gedeblokkeerd.
* Geen impliciete gegevensassociatie: Semaforen binden het synchronisatiemechanisme niet inherent aan specifieke gegevens. U kunt een semafoor gebruiken om de toegang tot een gedeelde bron te beheren, maar u moet de koppeling handmatig beheren.
* Monitoren:
* Gestructureerde aanpak: Monitors zijn meer gestructureerde programmeerconstructies. Ze kapselen:
* Gedeelde gegevens: Variabelen die de gedeelde bron vertegenwoordigen die wordt beschermd.
* Procedures/methoden: De bewerkingen die toegang krijgen tot de gedeelde gegevens en deze wijzigen. Dit zijn de enige routines die rechtstreeks toegang hebben tot de gedeelde gegevens.
* Conditievariabelen: (Belangrijk!) Speciale variabelen die worden gebruikt voor signalering en wachten binnen de monitor.
* Expliciete wederzijdse uitsluiting: Monitoren zorgen voor impliciete wederzijdse uitsluiting. Er kan op elk moment slechts één thread/proces actief zijn *binnen* de monitor. Deze wederzijdse uitsluiting wordt automatisch door de monitor zelf afgedwongen.
2. Handhaving van wederzijdse uitsluiting:
* Semaforen:
* Handmatige handhaving: Semaforen vertrouwen erop dat programmeurs `wait()` en `signal()` operaties rond kritieke secties correct gebruiken. Het is aan de programmeur om ervoor te zorgen dat de wederzijdse uitsluiting goed wordt gehandhaafd. Fouten kunnen gemakkelijk worden geïntroduceerd. Het vergeten van een `signal()` kan bijvoorbeeld tot een impasse leiden. Het plaatsen van `wait()` of `signal()` buiten de bedoelde kritieke sectie kan gelijktijdigheidsproblemen veroorzaken.
* Foutgevoelig: Deze handmatige handhaving is foutgevoelig. Het is gemakkelijk om fouten te maken die wederzijdse uitsluiting doorbreken of impasses veroorzaken.
* Monitoren:
* Impliciete handhaving: Monitoren dwingen wederzijdse uitsluiting *impliciet* af. De taal/het systeem zorgt ervoor dat er slechts één thread tegelijk actief kan zijn in de monitor. Dit maakt het makkelijker om te redeneren en minder gevoelig voor fouten. De compiler of het runtime-systeem zorgt voor het vergrendelen en ontgrendelen.
3. Conditiesynchronisatie (wachten en signaleren):
* Semaforen:
* Algemeen doel, maar minder gestructureerd voor wachtende condities: Semaforen *kunnen* worden gebruikt voor conditiesynchronisatie (bijvoorbeeld wachten tot een bron beschikbaar komt). Het is echter een beetje omslachtig. Normaal gesproken hebt u afzonderlijke semaforen nodig voor wederzijdse uitsluiting en voor signaalvoorwaarden, waardoor de code complexer en foutgevoeliger wordt. U kunt tel-semaforen gebruiken om aan te geven hoeveel van een bron beschikbaar is.
* Monitoren:
* Conditievariabelen: Monitors gebruiken *condition-variabelen* specifiek voor conditiesynchronisatie. Deze bieden bewerkingen zoals:
* `wait(condition)`:De aanroepende thread heft de monitorvergrendeling op en wacht op de opgegeven `condition`. De thread wordt in een wachtrij geplaatst die bij die voorwaardevariabele hoort. De monitorvergrendeling wordt opgeheven zodat andere draden de monitor kunnen binnendringen.
* `signal(condition)`:Eén thread die wacht op de opgegeven `condition` wordt gewekt. De gesignaleerde thread verkrijgt opnieuw de monitorvergrendeling.
* `broadcast(condition)` (of `signalAll(condition)`):Maakt alle threads wakker die wachten op de opgegeven `condition`.
* Verbeterde structuur: Conditievariabelen zijn nauw verbonden met de monitor en de gedeelde gegevens ervan, waardoor het gemakkelijker wordt om de conditiesynchronisatie binnen de monitor te begrijpen en erover te redeneren.
4. Eigendom en verantwoordelijkheid:
* Semaforen:
* Geen duidelijk eigendom: Elke thread kan `wait()` of `signal()` op een semafoor. Er bestaat geen concept van het ‘bezitten’ van een semafoor.
* Monitoren:
* Duidelijk eigendom: Threads moeten de monitor binnenkomen (impliciet de monitorvergrendeling verkrijgen) voordat toegang wordt verkregen tot de gedeelde gegevens of conditievariabelen worden gesignaleerd. Dit dwingt een duidelijk eigendomsmodel af.
5. Herinvoer:
* Semaforen:
* Geen inherent concept van herintreding: Semaforen weten niet of de thread die `wait()` of `signal()` aanroept, de semafoor al bevat. Het opnieuw gebruiken van een semafoor (bijvoorbeeld dezelfde thread verwerft de semafoor meerdere keren zonder deze los te laten) kan gemakkelijk tot een impasse leiden.
* Monitoren:
* Over het algemeen niet-hernieuwd: Monitoren zijn doorgaans ontworpen om *niet-herintredend* te zijn. Een draad die al de monitorvergrendeling vasthoudt, kan niet opnieuw in de monitor terechtkomen. Dit vereenvoudigt het redeneren over de status van het programma, maar kan soms herstructureringscode vereisen. Sommige monitorimplementaties ondersteunen herintreding, maar dit komt minder vaak voor.
Samengevat:
| Kenmerk | Semaforen | Monitoren |
|-----------------|--------------------------------------- -|------------------------------------------------------|
| Structuur | Eenvoudige gehele variabelen | Gestructureerd construct met data, procedures en conditievariabelen |
| Wederzijdse uitsluiting | Handleiding (verantwoordelijkheid programmeur) | Impliciet (afgedwongen door de monitor zelf) |
| Conditiesynchronisatie | Kan worden gebruikt, maar minder gestructureerd | Expliciet met conditievariabelen (wachten, signaal, uitzenden) |
| Foutgevoelig | Foutgevoeliger door handmatig beheer | Minder foutgevoelig door impliciete handhaving |
| Eigendom | Geen duidelijk eigendom | Duidelijk eigendom (thread moet in de monitor komen) |
| Herintreding | Over het algemeen niet overwogen | Over het algemeen niet-herintredende |
Wanneer gebruik je welke:
* Semaforen: Hoewel ze nog steeds waardevol zijn, worden semaforen vaak gezien als een primitief op een lager niveau. Ze zijn handig wanneer een eenvoudig telmechanisme nodig is, of wanneer de synchronisatievereisten erg basaal zijn. Ze zijn ook nuttig in systemen waar monitoren niet standaard worden ondersteund.
* Monitoren: Monitoren hebben de voorkeur bij het omgaan met complexere synchronisatiescenario's. Hun gestructureerde aanpak, impliciete wederzijdse uitsluiting en conditievariabelen maken het gemakkelijker om correcte en onderhoudbare gelijktijdige code te schrijven. Monitors zijn zeer geschikt voor het beschermen van gedeelde datastructuren en het implementeren van synchronisatiepatronen. Veel moderne programmeertalen bieden ingebouwde ondersteuning voor monitors of soortgelijke constructies (bijvoorbeeld Java's `synchronized` trefwoord en `wait()`, `notify()`, `notifyAll()` methoden, of Python's `threading.Lock` en `threading.Condition`).
Voorbeeld (conceptueel - geen specifieke taal):
Semafoorvoorbeeld (conceptueel):
```
semafoor mutex =1; // Binaire semafoor voor wederzijdse uitsluiting
semafoorbronBeschikbaar =0; // Semafoor tellen voor beschikbare bronnen
// Onderwerp 1 (producent)
wacht(mutex);
// Gedeelde bron openen en wijzigen
// Bron toevoegen
signaal(mutex);
signaal(bronbeschikbaar); // Signaal dat een bron nu beschikbaar is
// Onderwerp 2 (Consument)
wachten(bronbeschikbaar); // Wacht tot er een bron beschikbaar komt
wacht(mutex);
// Gedeelde bron openen en wijzigen
// Consumeer hulpbronnen
signaal(mutex);
```
Monitorvoorbeeld (conceptueel):
```
monitor MijnMonitor {
gedeelde gegevens:...;
voorwaarde resourceBeschikbaar;
methode accessResource() {
// Impliciet monitorvergrendeling verkrijgen
while (bron is niet beschikbaar) {
wachten(bronbeschikbaar); // Monitorvergrendeling ontgrendelen, wachten op voorwaarde
}
// Gedeelde gegevens openen en wijzigen
// ...
signaal(bronbeschikbaar); // Signaalwachtdraad
// Laat de monitorvergrendeling impliciet los wanneer de methode terugkeert
}
methode addResource() {
// Impliciet monitorvergrendeling verkrijgen
//Voeg bron toe aan gedeelde gegevens
signaal(bronbeschikbaar); // Signaalwachtdraad
// Geef de monitorvergrendeling impliciet vrij
}
}
```
In het voorbeeld van de monitor wordt de wederzijdse uitsluiting automatisch door de monitor afgehandeld, waardoor deze minder foutgevoelig is. Conditievariabelen bieden een meer gestructureerde manier om met wachten en signaleren om te gaan, vergeleken met het rechtstreeks gebruiken van semaforen voor dit doel. |
