Semaphore: wat is het, werkingsprincipe en toepassing in thread-synchronisatie

Wat is Semaphore?

Semaphore — is een synchronisatieprimitief die een teller gebruikt om toegang tot een gedeelde bron te beheren. Het concept werd in 1965 voorgesteld door Edsger Dijkstra en werd de basis van alle moderne synchronisatiemechanismen in besturingssystemen.

Definitie en doel

Een semafoor is een integer variabele met twee atomaire bewerkingen: wait (acquire) en signal (release). De wait-bewerking verlaagt de teller en signal verhoogt deze. Wanneer de teller nul bereikt, wordt de thread die wait aanroept geblokkeerd totdat signal door een andere thread wordt uitgevoerd.

Het belangrijkste doel van een semafoor is het beschermen van kritieke secties tegen gelijktijdige toegang door meerdere threads. In tegenstelling tot mutex vereist een semafoor geen binding aan de eigenaarthread, waardoor het geschikt is voor een breder scala aan coördinatietaken.

Geschiedenis en theoretische basis

Het concept van de semafoor ontstond in de context van het besturingssysteem THE, ontwikkeld aan de Technische Hogeschool Eindhoven. Dijkstra formaliseerde de semafoor als een wiskundige abstractie en bewees dat deze voldoende is voor het implementeren van alle synchronisatieprimitieven.

Hoe werkt een semafoor?

Het mechanisme van de semafoor is gebaseerd op twee atomaire bewerkingen en een interne wachtrij. Bij het aanroepen van acquire controleert de thread de tellerwaarde en gaat ofwel verder met uitvoeren, of wordt geblokkeerd totdat de bron vrijkomt.

Teller en atomaire bewerkingen

Bij het maken van een semafoor wordt de beginwaarde van de vergunningenteller ingesteld. Elke acquire-aanroep verlaagt de teller met 1. Als de teller daarna negatief wordt, wordt de thread geblokkeerd. De release-bewerking verhoogt de teller en wekt een van de wachtende threads.

import java.util.concurrent.Semaphore

val semaphore = Semaphore(3)

fun accessResource() {
    semaphore.acquire()
    try {
        println("${Thread.currentThread().name} werkt")
    } finally {
        semaphore.release()
    }
}

Wachtrij en planning

Wanneer een thread acquire aanroept met een teller van nul, plaatst het besturingssysteem deze in de FIFO-wachtrij van de semafoor. De thread gaat naar de status BLOCKED en verbruikt geen processortijd. Na de release-aanroep gaat de eerste thread in de wachtrij naar de status RUNNABLE en krijgt toegang tot de bron.

Soorten semaforen

In de synchronisatietheorie worden twee hoofdtypen semaforen onderscheiden: binair (binary) en telbaar (counting). De keuze van het type hangt af van de specifieke taak van toegangsbeheer tot bronnen.

Binaire semafoor (Binary Semaphore)

Een binaire semafoor neemt alleen de waarden 0 en 1 aan. Qua gedrag lijkt het op een mutex, maar zonder de eigendomsvereiste — elke thread kan release uitvoeren. Dergelijke semaforen zijn handig voor het implementeren van gereedheidsvlaggen en gebeurtenissen tussen threads.

val ready = Semaphore(0)

fun producer() {
    Thread.sleep(1000)
    ready.release()
}

fun consumer() {
    ready.acquire()
    println("Gegevens zijn gereed")
}

Telbare semafoor (Counting Semaphore)

Telbare semafoor kan elke niet-negatieve waarde aannemen. Het wordt gebruikt voor het beheren van een pool van gelijksoortige bronnen waar meerdere exemplaren beschikbaar zijn. Bijvoorbeeld een pool van 5 netwerkverbindingen: elke acquire neemt een verbinding in beslag, release retourneert deze naar de pool.

Telbare semaforen zijn onmisbaar bij het beperken van de toegangssnelheid tot externe diensten en het implementeren van threadpools. Ze maken nauwkeurige controle van de mate van parallellisme mogelijk zonder handmatig threadbeheer.

Semaphore vs Mutex

Ontwikkelaars verwarren vaak semafoor en mutex, hoewel er fundamentele verschillen tussen beide zijn. Het begrijpen van deze verschillen is cruciaal voor het kiezen van het juiste synchronisatiemechanisme in een project.

Eigendomsprincipe

Het belangrijkste verschil — het concept van eigendom. Mutex weet altijd welke thread hem heeft ingenomen en alleen die thread kan hem vrijgeven. Een semafoor heeft geen eigenaar: elke thread kan release aanroepen, zelfs zonder acquire aan te roepen. Dit maakt mutex veiliger voor gegevensbescherming en semafoor flexibeler voor coördinatie.

Prestaties en gebruiksscenario’s

In de praktijk is mutex sneller voor eenvoudige wederzijdse vergrendeling dankzij optimalisaties voor het typische scenario. Een semafoor vereist extra overhead voor het onderhouden van de teller. Voor het beperken van parallellisme of het implementeren van het patroon “producent-consument” is een semafoor echter onmisbaar.

Toepassing van Semaphore in mobiele ontwikkeling

Bij de ontwikkeling van mobiele applicaties wordt Semaphore gebruikt voor het beheren van toegang tot beperkte bronnen: netwerkverbindingen, bestanden, databases en hardwarecomponenten. Moderne platforms bieden handige ingebouwde implementaties.

Pool van serververbindingen

Een van de typische gevallen — een pool van HTTP-verbindingen. De applicatie kan maximaal 4 gelijktijdige verzoeken naar de server sturen, omdat de API van de provider parallellisme beperkt. Een semafoor met beginwaarde 4 garandeert dat bij elke belasting het aantal gelijktijdige verzoeken de limiet niet overschrijdt en de overige threads in de wachtrij wachten.

Zonder semafoor kan bij een plotselinge toename van gebruikersactiviteit de serverinfrastructuur overbelast raken, wat leidt tot time-outs en fouten 429 Too Many Requests. Semafoor werkt als een zekering die strikt een bepaald aantal gelijktijdige aanroepen doorlaat, ongeacht het aantal actieve threads.

Semaphore in Kotlin voor Android

Android biedt de klasse Semaphore uit het pakket java.util.concurrent. Laten we een voorbeeld bekijken van het beperken van gelijktijdige netwerkverzoeken tot twee threads om overbelasting van de server te voorkomen.

class ApiClient {
    private val throttle = Semaphore(2)

    suspend fun fetch(url: String): Result {
        throttle.acquire()
        return try {
            httpGet(url)
        } finally {
            throttle.release()
        }
    }
}

DispatchSemaphore in Swift voor iOS

In iOS lost DispatchSemaphore van GCD dezelfde taak op. Ontwikkelaars gebruiken het voor het synchroniseren van toegang tot bronnen in asynchrone code zonder de hoofdthread te blokkeren.

let semaphore = DispatchSemaphore(value: 3)

func processBatch(_ items: [UIImage]) {
    for img in items {
        semaphore.wait()
        DispatchQueue.global().async {
            applyFilter(to: img)
            semaphore.signal()
        }
    }
}

Typische fouten bij het werken met semaforen

De meest voorkomende fout — vergeten release bij een uitzondering. Als een thread met een fout eindigt voordat release wordt aangeroepen, blijft de semafoor voor altijd geblokkeerd voor de andere threads. Gebruik try/finally of defer voor gegarandeerde vrijgave. Het tweede probleem is deadlock bij het innemen van meerdere semaforen in verschillende volgorde door verschillende threads.

Patronen voor het gebruik van semaforen

Semaforen worden niet alleen gebruikt voor gegevensbescherming, maar ook voor coördinatie van threads in complexe multithread-scenario’s. Kennis van veelvoorkomende patronen versnelt de ontwikkeling en vermindert de kans op synchronisatiefouten.

Er zijn verschillende bewezen patronen voor het toepassen van semaforen in echte projecten. Het kennen ervan helpt typische fouten te voorkomen en betrouwbare multithread-systemen te bouwen.

Rate Limiter (snelheidsbeperking)

Een semafoor met beginwaarde N en periodieke release via een timer implementeert snelheidsbeperking van verzoeken naar de API. Bijvoorbeeld, de dienst staat 10 verzoeken per seconde toe: de semafoor start met 10, elk verzoek verlaagt de teller en een aparte TimerTask herstelt eenmaal per seconde de teller naar de beginwaarde. Dit beschermt zowel de applicatie als de server tegen overbelasting.

Producent-Consument via semaforen

In de klassieke producent-consument taak beheren twee semaforen de buffer: empty (schrijfvergunningen) en full (leesvergunningen). De producent roept acquire aan op empty en release op full, de consument — omgekeerd. Dit schema garandeert dat de consument nooit een lege buffer leest en de producent deze niet overvult.

Hetzelfde schema vormt de basis van de begrensde buffer in besturingssystemen — de ringbuffer met vaste grootte. In mobiele applicaties wordt dit patroon gebruikt voor het verwerken van wachtrijen met afbeeldingen, videobestanden en analytische gebeurtenissen.

Throttling van netwerkverzoeken

Semaforen worden succesvol gebruikt voor throttling van netwerkoproepen in achtergronddiensten. Bijvoorbeeld, een analytische applicatie stuurt gebeurtenispakketten naar de server. Zonder beperking van gelijktijdige threads kan bij piekbelastingen (opstarten van de applicatie, synchronisatie na offline) het aantal gelijktijdige verzoeken de serverlimieten overschrijden. Een semafoor met beginwaarde 3 garandeert soepel verzenden en voorkomt blokkering aan de serverzijde.