Dela via

Att jämföra Concurrency Runtime med andra samtidighetsmodeller

Det här dokumentet beskriver skillnaderna mellan funktionerna och programmeringsmodellerna i Concurrency Runtime och andra tekniker. Genom att förstå hur fördelarna med Concurrency Runtime kan jämföras med fördelarna med andra programmeringsmodeller kan du välja den teknik som bäst uppfyller kraven för dina program.

Om du för närvarande använder en annan programmeringsmodell, till exempel Windows-trådpoolen eller OpenMP, finns det situationer där det kan vara lämpligt att migrera till Concurrency Runtime. Till exempel beskriver ämnet Migrera från OpenMP till Concurrency Runtime när det kan vara lämpligt att migrera från OpenMP till Concurrency Runtime. Men om du är nöjd med programprestanda och aktuellt felsökningsstöd krävs inte migrering.

Du kan använda funktionerna och produktivitetsfördelarna med Concurrency Runtime för att komplettera ditt befintliga program som använder en annan samtidighetsmodell. Concurrency Runtime kan inte garantera belastningsutjämning när flera schemaläggare konkurrerar om samma databehandlingsresurser. Men när arbetsbelastningar inte överlappar varandra är den här effekten minimal.

Sektioner

Jämföra förebyggande schemaläggning med kooperativ schemaläggning

Den förebyggande modellen och modeller för samarbetsschemaläggning är två vanliga sätt att göra det möjligt för flera uppgifter att dela databehandlingsresurser, till exempel processorer eller maskinvarutrådar.

Förebyggande och samarbetsinriktad schemaläggning

Förebyggande schemaläggning är en resursallokering, prioritetsbaserad mekanism som ger varje uppgift exklusiv åtkomst till en beräkningsresurs under en viss tidsperiod och sedan växlar till en annan aktivitet. Förebyggande schemaläggning är vanligt i operativsystem för multitasking, till exempel Windows. Samarbetsschemaläggning är en mekanism som ger varje uppgift exklusiv åtkomst till en beräkningsresurs tills aktiviteten är klar eller tills aktiviteten ger sin åtkomst till resursen. Concurrency Runtime använder samarbetsschemaläggning tillsammans med den förebyggande schemaläggaren för operativsystemet för att uppnå maximal användning av bearbetningsresurser.

Skillnader mellan förebyggande och kooperativa schemaläggare

Förebyggande schemaläggare försöker ge flera trådar lika åtkomst till beräkningsresurser för att säkerställa att varje tråd gör framsteg. På datorer som har många databehandlingsresurser blir det mindre problematiskt att säkerställa rättvis åtkomst. Att säkerställa en effektiv användning av resurserna blir dock mer problematiskt.

En preemptiv kernel-mode-schemaläggare kräver att programkoden förlitar sig på operativsystemet för schemaläggningsbeslut. Omvänt kan en kooperativ schemaläggare i användarläge göra det möjligt för programkod att fatta egna schemaläggningsbeslut. Eftersom kooperativ schemaläggning gör att många schemaläggningsbeslut kan fattas av programmet, minskar det mycket av de omkostnader som är associerade med synkronisering i kernelläge. En kooperativ schemaläggare defererar vanligtvis schemaläggningsbeslut till operativsystemets kernel när den inte har något annat arbete att schemalägga. En kooperativ schemaläggare defererar också till schemaläggaren för operativsystemet när det finns en blockeringsåtgärd som kommuniceras till kerneln, men den åtgärden kommuniceras inte till schemaläggaren i användarläge.

Schemaläggning och effektivitet för samarbete

För en förebyggande schemaläggare är allt arbete som har samma prioritetsnivå lika. En förebyggande schemaläggare schemalägger vanligtvis trådar i den ordning de skapas. Dessutom ger en preemptiv schemaläggare varje tråd ett tidskvantum på ett rundturssätt, baserat på trådprioritet. Även om den här mekanismen ger rättvisa (varje tråd gör framsteg framåt), kommer den till en viss kostnad för effektivitet. Till exempel kräver många beräkningsintensiva algoritmer inte rättvisa. I stället är det viktigt att relaterade uppgifter slutförs under den minsta totala tiden. Med samarbetsschemaläggning kan ett program schemalägga arbete på ett effektivare sätt. Tänk dig till exempel ett program som har många trådar. Schemaläggning av trådar som inte delar resurser för att köras samtidigt kan minska synkroniseringskostnaderna och därmed öka effektiviteten. Ett annat effektivt sätt att schemalägga aktiviteter är att köra pipelines med aktiviteter (där varje uppgift fungerar på utdata från den föregående) på samma processor så att indata för varje pipelinesteg redan läses in i minnescachen.

Använda förebyggande och samarbetsinriktad schemaläggning tillsammans

Kooperativ schemaläggning löser inte alla schemaläggningsproblem. Till exempel kan uppgifter som inte ger rättvis avkastning till andra uppgifter förbruka alla tillgängliga beräkningsresurser och hindra andra uppgifter från att göra framsteg. Concurrency Runtime använder effektivitetsfördelarna med samarbetsschemaläggning för att komplettera rättvisegarantierna för förebyggande schemaläggning. Som standardinställning tillhandahåller Concurrency Runtime en kooperativ schemaläggare som använder en arbetsstöldsalgoritm för att effektivt distribuera arbete mellan beräkningsresurser. Men concurrency Runtime-schemaläggaren förlitar sig också på den förebyggande schemaläggaren för operativsystemet för att fördela resurser mellan program på ett rättvist sätt. Du kan också skapa anpassade schemaläggare och schemaläggarprinciper i dina program för att skapa detaljerad kontroll över trådkörning.

[Topp]

Jämförelse mellan Concurrency Runtime och Windows-API:et

Programmeringsgränssnittet för Microsoft Windows-program, som vanligtvis kallas Windows API (och tidigare kallat Win32), tillhandahåller en programmeringsmodell som möjliggör samtidighet i dina program. Concurrency Runtime bygger på Windows-API:et för att tillhandahålla ytterligare programmeringsmodeller som inte är tillgängliga från det underliggande operativsystemet.

Concurrency Runtime bygger på Windows API-trådmodellen för att utföra parallellt arbete. Den använder också minneshantering i Windows API och mekanismer för trådlokal lagring. På Windows 7 och Windows Server 2008 R2 använder den Windows API-stöd för användarschemabara trådar och datorer som har fler än 64 maskinvarutrådar. Concurrency Runtime utökar Windows API-modellen genom att tillhandahålla en kooperativ uppgiftsschemaläggare och en arbetsstöldsalgoritm för att maximera användningen av beräkningsresurser, samt genom att möjliggöra flera samtidiga schemaläggare.

Programmeringsspråk

Windows API använder programmeringsspråket C för att exponera programmeringsmodellen. Concurrency Runtime tillhandahåller ett C++-programmeringsgränssnitt som utnyttjar de senaste funktionerna i C++-språket. Lambda-funktioner ger till exempel en kortfattad, typsäker mekanism för att definiera parallella arbetsfunktioner. Mer information om de senaste C++-funktionerna som concurrency Runtime använder finns i Översikt.

Trådar och trådpooler

Den centrala samtidighetsmekanismen i Windows-API:et är tråden. Du använder vanligtvis funktionen CreateThread för att skapa trådar. Även om trådar är relativt enkla att skapa och använda allokerar operativsystemet en betydande tid och andra resurser för att hantera dem. Även om varje tråd garanterat får samma körningstid som alla andra trådar på samma prioritetsnivå, kräver de associerade omkostnaderna att du skapar tillräckligt stora uppgifter. För mindre eller mer detaljerade uppgifter kan de omkostnader som är associerade med samtidighet uppväga fördelarna med att köra aktiviteterna parallellt.

Trådpooler är ett sätt att minska kostnaden för trådhantering. Med anpassade trådpooler och implementeringen av trådpoolen som tillhandahålls av Windows API kan både små arbetsobjekt köras parallellt på ett effektivt sätt. Windows-trådpoolen hanterar arbetsobjekt i en först-i-först-ut-kö (FIFO). Varje arbetsobjekt startas i den ordning som det lades till i poolen.

Concurrency Runtime implementerar en algoritm för arbetsstöld för att utöka FIFO-schemaläggningsmekanismen. Algoritmen flyttar arbetsuppgifter som ännu inte har startats till trådar som behöver fler arbetsobjekt. Även om algoritmen för arbetsstöld kan balansera arbetsbelastningar kan det också leda till att arbetsobjekt sorteras om. Den här omordningsprocessen kan leda till att ett arbetsobjekt startas i en annan ordning än den skickades. Detta är användbart med rekursiva algoritmer, där det finns en bättre chans att data delas mellan nyare uppgifter än mellan äldre. Att få de nya objekten att köras först innebär färre cachemissar och eventuellt färre sidfel.

Ur operativsystemets perspektiv är arbetsstöld orättvist. Men när ett program implementerar en algoritm eller uppgift som ska köras parallellt spelar rättvisa mellan underaktiviteterna ingen roll. Det viktiga är hur snabbt den övergripande uppgiften slutförs. För andra algoritmer är FIFO lämplig schemaläggningsstrategi.

Beteende på olika operativsystem

I Windows XP och Windows Vista fungerar program som använder Concurrency Runtime på liknande sätt, förutom att heap-prestanda förbättras i Windows Vista.

I Windows 7 och Windows Server 2008 R2 stöder operativsystemet ytterligare samtidighet och skalbarhet. Dessa operativsystem stöder till exempel datorer som har fler än 64 maskinvarutrådar. Ett befintligt program som använder Windows-API:et måste ändras för att dra nytta av dessa nya funktioner. Ett program som använder Concurrency Runtime använder dock automatiskt dessa funktioner och kräver inga ändringar.

användarläges schemaläggning

[Topp]

Jämförelse av Concurrency Runtime-miljön med OpenMP

Concurrency Runtime möjliggör en mängd olika programmeringsmodeller. Dessa modeller kan överlappa eller komplettera modellerna för andra bibliotek. I det här avsnittet jämförs Concurrency Runtime med OpenMP.

OpenMP-programmeringsmodellen definieras av en öppen standard och har väldefinierade bindningar till programmeringsspråken Fortran och C/C++. OpenMP-versionerna 2.0 och 2.5 passar bra för parallella algoritmer som är iterativa. De utför alltså parallell iteration över en matris med data. OpenMP är mest effektivt när graden av parallellitet är förutbestämd och matchar de tillgängliga resurserna i systemet. OpenMP-modellen är en särskilt bra matchning för databehandling med höga prestanda, där mycket stora beräkningsproblem fördelas över bearbetningsresurserna på en enda dator. I det här scenariot är maskinvarumiljön känd och utvecklaren kan rimligen förvänta sig att ha exklusiv åtkomst till beräkningsresurser när algoritmen körs.

Men andra, mindre begränsade databehandlingsmiljöer kanske inte är en bra matchning för OpenMP. Rekursiva problem (till exempel snabbsortsalgoritmen eller sökning i ett dataträd) är till exempel svårare att implementera med hjälp av OpenMP. Concurrency Runtime kompletterar funktionerna i OpenMP genom att tillhandahålla PPL ( Parallel Patterns Library ) och Asynchronous Agents Library. Till skillnad från OpenMP tillhandahåller Concurrency Runtime en dynamisk schemaläggare som anpassar sig till tillgängliga resurser och justerar graden av parallellitet när arbetsbelastningarna ändras.

Många av funktionerna i Concurrency Runtime kan utökas. Du kan också kombinera befintliga funktioner för att skapa nya. Eftersom OpenMP förlitar sig på kompilatordirektiv kan det inte utökas enkelt.

Mer information om hur Concurrency Runtime jämförs med OpenMP och hur du överför befintlig OpenMP-kod för att använda Samtidighetskörning kan du läsa i Migrera från OpenMP till Concurrency Runtime.

[Topp]

Se även

Samtidighetskörning
Översikt
PPL (Parallel Patterns Library)
Asynkront agentbibliotek
OpenMP