Synkroniser JavaScript-Koden Din Med Async-Mutex

Bestilt Serverteller

eksemplet ovenfor er en bestilt serverteller som vi ønsker å bygge. Når du klikker på knappen:

• En asynkron forespørsel sendes til en server
• serveren øker en intern teller
• serveren returnerer gjeldende tellerverdi
• klienten (vår nettside) viser telleren i En Skål vist ovenfor.

det er viktig at rekkefølgen på tallene bevares når de mottas. Så hvordan kan vi synkronisere rekkefølgen på forespørslene? Vi vet at nettverksforespørsler er asynkrone. Det er fullt mulig for den første forespørselen å ta lengre tid å ankomme enn den andre forespørselen, eller den andre forespørselen å ta lengre tid enn den tredje forespørselen, og så videre. Dette out-of-order ankomst av forespørsler vil være et problem for vår søknad.

‘ingen synkronisering’ tilnærming

Hva ville skje hvis vi skulle utvikle dette programmet uten synkroniseringskonstruksjoner? Her er et eksempel implementering av en simulering av dette programmet uten synkronisering.

serveren simuleres med processCommmand(), og nettverksforsinkelsene simuleres med serverDelay(). Siden det ikke er noen synkroniseringsmekanismer, når knappen «Klikk meg» er klikket, blir en ny forespørsel sparket av umiddelbart.

dette er resultatet av denne implementeringen.

Uh oh-tallene, som forventet, viser opp out-of-order, og vi har ikke klart å gjøre vår søknad for å vise tall i rekkefølge.

Overvinne out-of-order problemet Med Mutex

problemet er at nettverksforespørsler er ute av drift, men vår søknad vil at de skal være i orden. En måte å løse dette på er å bruke En Mutex-lås for å bare tillate at en forespørsel behandles om gangen, og blokkere de andre forespørslene til det er deres tur.

her er implementeringen Med Mutex.

Mutex API – bruksflyten er følgende:

• Linje 23: en forespørsel om å skaffe clientLock er initiert. Denne forespørselen vil blokkere hvis noen andre allerede har kjøpt låsen og ikke har sluppet den ennå
• Linje 33: klientlåsen frigjøres etter at serveren har svart og vi har vist toast. Dette gjør at andre knappen klikk hendelser for å nå konkurrere om låsen og starte sin server network request!

denne låsemekanismen garanterer at bare en knapphendelse vil bli behandlet om gangen, blokkering og kø de andre. Vi har nå oppnådd den planlagte bestilte implementeringen av vårt opprinnelige eksempel vist i begynnelsen!

Begrensende antall synlige Toasts

hva om du ikke liker at flere Toasts kan oversvømme skjermen om gangen? Vi kan utvide vår logikk for å begrense antall Toasts som vises om gangen. Vår synkroniseringskonstruksjon her ville være En Semafor!

Tenk På En Sempahore som En Mutex, men det kan tillate flere asynkrone forespørsler å utføre et stykke kode om gangen. Du kan også konfigurere maksimalt antall!

Ved Å bruke En Mutex og Semafor, kunne jeg begrense antall Toasts på skjermen til 2 om gangen.

og her er koden knyttet til eksemplet ovenfor

Linje 6

Sempahore-strukturen initialiseres med verdien 2, som angir at bare maksimalt 2 toasts kan vises en gang.

Linje 26-31

vår semaforlogikk kommer til å hjelpe oss når vi vil vise Toast. Vi prøver å skaffe Sempahore. Hvis vi ble lyktes, lager vi Toastobjektet, og så passerer vi releaseSemaphore() til completeCallback – funksjonen Til Toast. Denne tilbakeringingen kalles når toast er avvist.