Ordered Server Counter
yllä oleva esimerkki on tilattu palvelinlaskuri, jonka haluamme rakentaa. Kun klikkaat painiketta:
- asynkroninen pyyntö lähetetään palvelimelle
- palvelin lisää sisäisen laskurin
- palvelin palauttaa nykyisen laskurin arvon
- asiakas (verkkosivumme) näyttää laskurin yllä esitetyssä maljassa.
on tärkeää, että numeroiden järjestys säilyy vastaanotettaessa. Miten voimme synkronoida pyyntöjen järjestyksen? Tiedämme, että verkkopyynnöt ovat asynkronisia. On täysin mahdollista, että ensimmäisen pyynnön saapuminen kestää kauemmin kuin toisen pyynnön, tai toisen pyynnön saapuminen kestää kauemmin kuin kolmannen pyynnön, ja niin edelleen. Tämä out-of-order saapuminen pyyntöjä tulee olemaan ongelma hakemuksemme.
’ei synkronointia’ – lähestymistapa
mitä tapahtuisi, jos kehittäisimme tämän sovelluksen ilman synkronointikonstruktioita? Tässä on näyte täytäntöönpanoa simulointi tämän sovelluksen ilman synkronointia.
palvelinta simuloidaan numerolla processCommmand() ja verkon viiveitä simuloidaan numerolla serverDelay() . Koska synkronointimekanismeja ei ole, kun painiketta ”Klikkaa minua” napsautetaan, Uusi pyyntö laukaistaan välittömästi.
tämä on tämän toteutuksen tulos.
Uh oh-numerot, kuten odotettiin, näkyvät epäkunnossa, ja emme ole tehneet hakemusta näyttää numerot järjestyksessä.
epäkunnossa olevan ongelman ratkaiseminen Mutexin kanssa
kysymys on siitä, että verkkopyynnöt ovat epäkunnossa, mutta hakemuksemme haluaa niiden olevan kunnossa. Yksi tapa ratkaista tämä on käyttää Mutex-lukkoa, joka sallii vain yhden pyynnön käsittelyn kerrallaan ja estää muut pyynnöt, kunnes on niiden vuoro.
tässä on toteutus Mutexilla.
Mutex API usage flow on seuraava:
- rivi 23:
clientLock: n hankkimista koskeva pyyntö on vireillä. Tämä pyyntö estyy, jos joku muu on jo hankkinut lukon eikä ole julkaissut sitä vielä - rivi 33: asiakaslukko vapautetaan, kun palvelin on vastannut ja olemme näyttäneet maljan. Näin muut napin painallustapahtumat voivat nyt kilpailla lukituksesta ja aloittaa palvelinverkkopyyntönsä!
tämä lukitusmekanismi takaa sen, että vain yksi nappitapahtuma prosessoidaan kerrallaan, estäen ja jonottaen muut. Olemme nyt saavuttaneet alkuperäisen alussa esitetyn esimerkin aiotun tilatun toteutuksen!
näkyvien paahtoleipien määrän rajoittaminen
mitä jos et pidä siitä, että useampi paahtoleipä voi tulvia näytölle kerrallaan? Voimme laajentaa logiikkaamme rajoittaaksemme maljojen määrää kerrallaan. Synkronointirakenteemme tässä olisi Semafori!
ajattele Sempahorea kuin Mutexia, mutta se voi mahdollistaa useiden asynkronisten pyyntöjen suorittamisen koodinpätkällä kerrallaan. Voit myös määrittää enimmäismäärän!
pystyin Mutexia ja semaforia käyttäen rajoittamaan kuvaruudun maljapuheiden määrän kahteen kerrallaan.
ja tässä on koodi, joka liittyy siihen yllä olevaan esimerkkiin
rivi 6
Sempahore-rakenne on alustettu arvolla 2, joka määrittää, että kerrallaan voidaan näyttää vain korkeintaan 2 paahtoleipää.
rivi 26-31
semaforilogiikkamme tulee avuksi, kun haluamme nostaa maljan esille. Yritämme hankkia Sempahoren. Jos onnistuimme, luomme Paahtoleipäobjektin ,jonka jälkeen siirrymme releaseSemaphore() paahtoleivän completeCallback funktioon. Tämä takaisinkutsu soitetaan, kun malja on poistettu.
