7. fejezet

többszálú

Az összes figyelem az egérmutatót, akkor könnyű elfelejteni, hogy vége - csak egy része a kérelmet. Megjelenése után a kurzor a kérelmet nem lehet alapvetően különbözik a fent, úgy, hogy nem lenne kívánatos, hogy írja be a kódot bemenet az egér és a kurzor a közepén az alkalmazás frissítése. És akkor is, ha egyetért ebben, mivel ez a kód nézne? Meg kell folyamatosan ellenőrzi az új adatok az egeret. Észlelése esetén az adatok akkor frissíti a kurzort; egyébként normál üzemmódban folytatja. Állandó felmérés egér lassú alkalmazás és összetettségét szerkezetét. Jobb megoldás - szét a kérelmet két részfeladat segítségével többszálú.

Ha már ismeri a koncepció multi-threading, ez a rész nem lesz szükség. Azonban a kezdők, ez foglalkozik a főbb rendelkezéseit, meg kell tanulni, mielőtt a programozás. Semmilyen körülmények között nem szabad úgy értelmezni, mint egy átfogó útmutató a menet.

Patakok és folyamatok

Ön tisztában van, akár nem, akkor már ismeri a szálak és folyamatok. Minden alkalommal, amikor egy új folyamat jön létre, amikor a program elindul. Az eljárás lehetővé teszi, hogy a program minden kellett dolgoznia, köztük egy szál (thread). Ez a szabvány patak (más néven a fő stream - primer menet) használják a program végrehajtásához kódot. A fő áramlási tipikus folyamat kezdődik a belépési pontot (Windows-alapú programok a funkció WinMain ()), és továbbra is megfelelően elvégzett minden hurkok, feltételes utasítások és funkció hívásokat. A fő stream elkészül a folyamat befejezése.

Azonban semmi korlátozza egy technológiai folyamatból. MFC vagy Win32 eszközök lehetővé teszik, hogy további szálak, amelyek általánosan használt elvégzésére háttér feladatokat. Ezek a további hullámok (néha workflow) függetlenül működik a fő áramlási (valamint egymástól). Minden szál saját stack, de a rendszer erőforrások (például fájlok és dinamikus memória) között oszlik szálak.

Miért multi-threading?

A többszálas előnyös, ha több feladatot, amely (legalábbis részben) egyidejű működésre. Kódot helyesen írta többszálas alkalmazások egyszerűnek tűnik, hiszen minden szál végez egy adott feladatot.

Másrészt, a többszálas alkalmazás nehezebb írni és hibakeresés. Meg kell szinkronizálni többszálú hozzáférést a megosztott erőforrások, hogy elkerüljék kiszámíthatatlan eredményeket, valamint végrehajtásának koordinálása függő kódot, hogy biztosítsák a megfelelő események sorozata.

Még egy utolsó pont: az egyprocesszoros számítógép, többszálas alkalmazások nem futnak gyorsabban egyszálú. A sebesség növekedésével csak többprocesszoros számítógép több operációs rendszert (pl Windows NT).

szálszinkronizációt

Új patak a program egyszerű - ez sokkal nehezebb megszervezni a végrehajtás és a befejezés, sok funkciója többszálú API kifejezetten szálszinkronizációt. Ebben a részben röviden áttekintjük az ilyen szinkronizálás.

Streams összehangolják az Event (esemény), amely közvetíti az információt az állapotáról egy vagy több forrásból. Az esemény lehet állítani (jelzett), vagy eldobjuk (unsignaled). A konkrét tartalmát az események változó lehet, de általában ezek jelfolyamatábráját elzáródás.

Elzárják lehet elképzelni, mint egy hurok, folyamatosan lekérdező bizonyos logikai változót. A ciklus folytatódik, amíg a változó nem az értéke TRUE. Egy műszaki szempontból, ez nem teljesen pontos, mert gátolta az események láncolatába nem termel aktív szavazás. Ehelyett felfüggesztésre kerül, és a rendszer eltávolítja a listán az aktív szálak. Csak miután a blokkoló esemény fog menni a telepített állapotban van, a menet folytatódik. Ennek megfelelően zárolt szál alig fogyaszt a CPU időt.

Blokkoló flow a leggyakrabban használt, hogy megvédje a megosztott erőforrások egyidejű hozzáférést több szál. Mutex (mutex csökkentését egymást kölcsönösen kizáró, azaz „kölcsönösen kizárják”) egy olyan objektum, lehet bármikor tulajdonában csak egy szál, amely biztosítja a biztonságos hozzáférést kapcsolódó források. Amikor a mutex tartozik egy patak, minden más szálak meg kell kérni, a rendelkezésére álló, hogy engedje el a mutex zárva.

Kritikus szakaszok (kritikus szakasz), mint a mutexes, arra használják, hogy megakadályozzák egyidejű hozzáférést egy erőforrás több szál. Azonban, ha a mutex szinkronizálhatja a folyamatok közötti áramok, a kritikus szakasz korlátozódik az azonos folyamatábra. Korlátozása sebesség kompenzálja - kritikus szakasz gyorsabb, mint a mutex.

Szemaforokat (szemafor) is lehet használni, hogy korlátozza a hozzáférést az erőforrásokhoz, de ellentétben mutexek vagy a szemafor a kritikus szakaszok lehetővé teszi az egyidejű hozzáférést több szál. A szálak maximális száma egy időben való hozzáférés az erőforrás határozza meg, hogy hozzon létre egy szemafor. Ezután hozzáférést biztosít az összes felfelé áramlik, amíg számuk eléri az előre meghatározott határértéket. Minden más szálak szeretnének hozzáférés le van tiltva, amíg egy vagy több folyamot nem fog működni az erőforrás.

Osztályok folyik MFC

Többszálú programozás Windows, akkor választhat osztályok MFC és a Win32 streaming funkciók. A Microsoft azt javasolja, hogy használja a MFC-alkalmazás osztály folyik. A szálak MFC a következő osztályokba:

Class CWinThread jelentése külön áramban. Jelen van minden alkalmazás, mert a CWinApp osztály (a bázis osztály DirectDrawApp) származik CWinThread. Ebben az esetben a fő stream CWinThread alkalmazás; hogy új munkafolyamatok létrehozása CWinThread tárgyakat.

CSyncObject osztály virtuális. Az azonnali létrehozását esetekben ez az osztály nem megengedett; ez már csak annak érdekében, hogy a funkció a származtatott osztályok. CSyncObject osztály az alap osztály számára CEvent. CCriticalSection. CMutex és CSemaphore. Szinkronizációs objektum képviseli ezen osztályok tárgyalt az előző részben.

Osztályba tartozó CSingleLock CMultiLock és használt, hogy blokkolja az áramlás, mint egy vagy több esemény. Class CSingleLock elzárja a telepítés előtt egy konkrét esemény, és CMultiLock - telepíteni egy vagy az összes esemény egy adott készlet.

Később ebben a fejezetben fogjuk használni az osztályok CWinThread. CEvent. CCriticalSSection és CMultiLock.