megrendelt szerver számláló
a fenti példa egy megrendelt szerver számláló, amelyet építeni akarunk. Ha rákattint a gombra:
- egy aszinkron kérést küld a szerver
- a szerver növeli a belső számláló
- a szerver visszaadja az aktuális számláló értéke
- a kliens (weboldalunk) megjeleníti a számláló egy pirítós fent látható.
fontos, hogy a számok sorrendje megmaradjon a beérkezéskor. Tehát hogyan tudjuk szinkronizálni a kérések sorrendjét? Tudjuk, hogy a hálózati kérelmek aszinkron. Teljesen lehetséges, hogy az első kérés megérkezése hosszabb ideig tart, mint a második kérés, vagy a második kérés hosszabb ideig tart, mint a harmadik kérés stb. Ez out-of-order érkezése kérések lesz a probléma az alkalmazás.
a ‘nincs szinkronizálás’ megközelítés
mi történne, ha ezt az alkalmazást szinkronizálási konstrukciók nélkül fejlesztenénk ki? Itt van egy minta végrehajtása szimuláció az alkalmazás nem szinkronizálás.
a kiszolgálót processCommmand() , a hálózati késéseket pedig serverDelay() segítségével szimulálják . Mivel nincsenek szinkronizálási mechanizmusok, ha a “Click me” gombra kattint, egy új kérés azonnal elindul.
ez a megvalósítás eredménye.
Uh oh-a számok, ahogy várható volt, jelennek meg out-of-order, és mi nem sikerült, hogy a kérelmet, hogy a számok sorrendben.
az out-of-order probléma leküzdése a Mutex
a probléma az, hogy a hálózati kérések rendben vannak, de alkalmazásunk azt akarja, hogy rendben legyenek. Ennek egyik módja a Mutex zár használata, amely egyszerre csak egy kérés feldolgozását teszi lehetővé, blokkolva a többi kérést, amíg rájuk nem kerül a sor.
itt van a végrehajtás Mutex.
a Mutex API Használati folyamata a következő:
- 23. sor: a
clientLockmegszerzésére irányuló kérelem megkezdődik. Ez a kérés blokkolja, ha valaki más már megszerezte a zárat, és még nem engedte el - 33. sor: az ügyfélzár feloldásra kerül, miután a szerver válaszolt, és megmutattuk a pirítóst. Ez lehetővé teszi, hogy más gomb kattintási események versenyezzenek a zárolásért, és kezdeményezzék a szerver hálózati kérését!
ez a reteszelő mechanizmus garantálja, hogy egyszerre csak egy gombesemény kerül feldolgozásra, blokkolja és sorba állítja a többit. Most elértük az elején bemutatott eredeti példánk tervezett rendezett megvalósítását!
a látható pirítósok számának korlátozása
mi van, ha nem tetszik, hogy egyszerre több pirítós eláraszthatja a képernyőt? Kiterjeszthetjük logikánkat, hogy korlátozzuk az egyszerre megjelenített pirítósok számát. A szinkronizációs konstrukciónk itt egy szemafor lenne!
Gondolj egy Sempahore-ra, mint egy Mutex, de lehetővé teszi, hogy egyszerre több aszinkron kérés hajtson végre egy kóddarabot. Beállíthatja a maximális számot is!
egy Mutex és szemafor segítségével egyszerre 2-re tudtam korlátozni a pirítósok számát a képernyőn.
itt van a fenti példához társított kód
6. sor
a Sempahore struktúra inicializálódik a 2 értékkel, amely meghatározza, hogy csak legfeljebb 2 pirítós jeleníthető meg egy időben.
Line 26-31
szemafor logikánk segít nekünk, amikor meg akarjuk jeleníteni a pirítóst. Megpróbáljuk megszerezni a Sempahore-t. Ha sikerült, akkor létrehozzuk a pirítós objektumot, majd átadjuk a releaseSemaphore() – ot a pirítós completeCallback funkciójának. Ezt a visszahívást akkor hívják meg, amikor a pirítóst elutasítják.
