geordende Serverteller
het voorbeeld hierboven is een geordende Server teller die we willen bouwen. Wanneer u op de knop klikt:
- een asynchrone aanvraag wordt verzonden naar een server
- de server verhoogt een interne teller
- de server geeft de huidige teller waarde
- de client (onze webpagina) toont de teller in een Toast hierboven.
het is belangrijk dat de volgorde van de nummers behouden blijft bij ontvangst. Hoe kunnen we de volgorde van de verzoeken synchroniseren? We weten dat netwerkverzoeken asynchroon zijn. Het is heel goed mogelijk dat het eerste verzoek langer duurt dan het tweede verzoek, of dat het tweede verzoek langer duurt dan het derde verzoek, enzovoort. Deze out-of-order aankomst van verzoeken zal een probleem voor onze toepassing.
de ‘no synchronization’ benadering
wat zou er gebeuren als we deze applicatie zonder synchronisatieconstructies zouden ontwikkelen? Hier is een voorbeeld implementatie van een simulatie van deze applicatie zonder synchronisatie.
de server wordt gesimuleerd met processCommmand() en de netwerkvertragingen worden gesimuleerd met serverDelay() . Aangezien er geen synchronisatiemechanismen zijn, wordt zodra op de knop “klik op mij” wordt geklikt, een nieuw verzoek onmiddellijk afgevuurd.
Dit is het resultaat van deze implementatie.
Uh oh-de nummers, zoals verwacht, worden weergegeven buiten-van-orde, en we hebben gefaald om onze aanvraag om nummers in volgorde te laten zien.
overwinnen van de out-of-order kwestie met Mutex
het probleem is dat netwerk verzoeken niet in orde zijn, maar onze toepassing wil dat ze in orde zijn. Een manier om dit op te lossen is door een Mutex-slot te gebruiken om slechts één verzoek tegelijk te verwerken, waarbij de andere verzoeken worden geblokkeerd totdat het hun beurt is.
hier is de implementatie met Mutex.
de Mutex API gebruik stroom is de volgende:
- lijn 23: er wordt een verzoek ingediend om de
clientLockte verwerven. Dit verzoek zal blokkeren als iemand anders de lock al heeft verworven en het nog niet heeft vrijgegeven - regel 33: de client lock wordt vrijgegeven nadat de server heeft gereageerd en we de toast hebben getoond. Dit maakt het mogelijk andere knop Klik evenementen om nu te concurreren voor het slot en initiëren van hun server netwerk verzoek!
dit vergrendelingsmechanisme garandeert dat slechts één knopgebeurtenis tegelijk wordt verwerkt, de andere wordt geblokkeerd en in de wachtrij geplaatst. We hebben nu de beoogde geordende implementatie van ons originele voorbeeld uit het begin bereikt!
beperkt aantal zichtbare Toasts
wat als het u niet bevalt dat meerdere Toasts het scherm tegelijk kunnen overspoelen? We kunnen onze logica uitbreiden om het aantal Toast per keer te beperken. Onze synchronisatieconstructie hier zou een semafoor zijn!
denk aan een Sempahore als een Mutex, maar het kan meerdere asynchrone Verzoeken toestaan om een stuk code tegelijk uit te voeren. U kunt het maximum aantal ook configureren!
met een Mutex en semafoor kon ik het aantal Toasts op het scherm beperken tot 2 per keer.
en hier is de code geassocieerd met het bovenstaande voorbeeld
regel 6
de Sempahore-structuur wordt geïnitialiseerd met de waarde 2, die aangeeft dat slechts maximaal 2 toasts per tijd kunnen worden weergegeven.
lijn 26-31
onze semafoorlogica helpt ons wanneer we de Toast willen tonen. We proberen de Sempahore te bemachtigen. Als het ons gelukt is, dan maken we het Toast object, en dan geven we releaseSemaphore() door aan de completeCallback functie van de Toast. Deze callback wordt genoemd wanneer de toast wordt verworpen.
