bestilt Server tæller
eksemplet ovenfor er en bestilt servertæller, som vi ønsker at bygge. Når du klikker på knappen:
- en asynkron anmodning sendes til en server
- serveren øger en intern tæller
- serveren returnerer den aktuelle tællerværdi
- klienten (vores hjemmeside) viser tælleren i en skål vist ovenfor.
det er vigtigt, at rækkefølgen af numrene bevares, når de modtages. Så hvordan kan vi synkronisere rækkefølgen af anmodningerne? Vi ved, at netværksanmodninger er asynkrone. Det er helt muligt, at den første anmodning tager længere tid at ankomme end den anden anmodning, eller den anden anmodning tager længere tid end den tredje anmodning osv. Denne out-of-order ankomst af anmodninger vil være et problem for vores ansøgning.
tilgangen’ ingen synkronisering ‘
hvad ville der ske, hvis vi skulle udvikle denne applikation uden synkroniseringskonstruktioner? Her er en prøve implementering af en simulering af denne ansøgning uden synkronisering.
serveren simuleres med processCommmand(), og netværksforsinkelserne simuleres med serverDelay(). Da der ikke er nogen synkroniseringsmekanismer, når knappen “Klik på mig” er klikket, fyres en ny anmodning straks af.
dette er resultatet af denne implementering.
uh oh — tallene, som forventet, vises ude af orden, og vi har undladt at gøre vores ansøgning om at vise numre i rækkefølge.
overvinde out-of-order-problemet med Muteks
problemet er, at netværksanmodninger er ude af drift, men vores applikation ønsker, at de skal være i orden. En måde at løse dette på er at bruge en Muteks-lås til kun at tillade, at en anmodning behandles ad gangen og blokere de andre anmodninger, indtil det er deres tur.
her er implementeringen med Muteks.
API-brugsstrømmen er følgende:
- linje 23: en anmodning om at erhverve
clientLockindledes. Denne anmodning blokeres, hvis en anden allerede har erhvervet låsen og ikke har frigivet den endnu - linje 33: klientlåsen frigives, efter at serveren har svaret, og vi har vist toast. Dette gør det muligt for andre knapklikhændelser nu at konkurrere om låsen og starte deres servernetværksanmodning!
denne låsemekanisme garanterer, at kun en knaphændelse behandler ad gangen, blokerer og står i kø for de andre. Vi har nu opnået den tilsigtede ordnede implementering af vores originale eksempel vist i begyndelsen!
begrænsning af antal synlige Toasts
hvad hvis du ikke kan lide at flere Toasts kan oversvømme skærmen ad gangen? Vi kan udvide vores logik for at begrænse antallet af skåle, der vises ad gangen. Vores synkroniseringskonstruktion her ville være en semafor!
tænk på en Sempahore som en Muteks, men det kan tillade flere asynkrone anmodninger at udføre et stykke kode ad gangen. Du kan også konfigurere det maksimale antal!
ved hjælp af en Muteks og Semafor kunne jeg begrænse antallet af Toasts på skærmen til 2 ad gangen.
og her er koden tilknyttet det med eksemplet ovenfor
linje 6
sempahore-strukturen initialiseres med værdien 2, som angiver, at kun maksimalt 2 toasts kan vises en tid.
linje 26-31
vores semafor logik kommer til at hjælpe os, når vi ønsker at vise Toast. Vi forsøger at erhverve Sempahore. Hvis vi blev lykkedes, skaber vi Toastobjektet, og så sender vi releaseSemaphore() til completeCallback – funktionen af toasten. Denne tilbagekald kaldes, når skålen afvises.
