Vinnaren i pepparkakshustävlingen!
  • 1
  • 2
2017-03-28, 21:31
  #13
Medlem
Börjar bli rätt ont om miljöer som är begränsad till enbart time slicing. Även många microcontrollers börjar få multipla kärnor.
Citera
2017-03-29, 05:36
  #14
Medlem
MeanMEs avatar
Citat:
Ursprungligen postat av Trillske
Asynkron och parallell är två helt olika saker, och eftersom det står parallellism i topic bör det ju vara det som gäller. Att asynkron är enklare är inget som behöver preciseras, självfallet är det lättare att köra en tråd i taget.

EDIT: jag kanske menar concurrent (vad nu det heter) när jag tänker efter, blir lätt förvirrad när det är svenska.
Det gör det, men då det kombineras med villkoret att låsa en resurs så får du gärna ge en lösning för hur parallellism skulle kunna tillföra något här...
Låser du en resurs för en task i taget får du ju ett sekventiellt utfall per se.

Det du får göra är att dela upp de tasks som kommer in och se om du kan urskilja olika tasks som använder sig av helt oberoende resurser och slussa in dem i olika köer som jag skrev.
Dessa köer kan du då parallellköra mot varandra.

Du kan evt parallellköra varje tasks uppgifter.

Men sköta köerna som delar resurser sker bäst asynkront eller helt sekventiellt.
Och visst det finns metoder som du antyder:
Citat:
* Jag har för mig att MS Task-lib har fullt stöd för parallelism, d.v.s. att det faktiskt delegeras på ett hyfsat sätt på rätt burk utan att man behöver bry sig om det själv. Men citera mig inte.
De (MS) ger en timeout metod för att förhindra deadlocks vill jag minnas...
Det ger ju att du är tvungen att sätta olika timeout tider på ett antal nS för de olika trådarna som bromsar kön vid varje exekvering...

Känns ju inte så vettigt att göra då utfallet likt förbaskat blir sekventiellt och nu med en fördröjning dessutom.

Den vettigaste lösningen är just att designa det hela så det inte uppstår deadlocks över huvud taget.
Och då är det ett sekventiellt utfall från köerna som kommer vare sig TS söker något annat eller ej.

Du kan jobba runt det hela genom att utföra en analys av trafiken och komponera en resurshanterare som har en kö som den betar av asynkront för att förhindra ett stop och deadlocks vid varje task och bara få det vid intervallet av kölängden av resurshanteraren det kan räcka om du har tur men då kan du ju i de flesta fall lika gärna köra all köhantering asynkront redan från början.

I de fall detta funkar är ju ifall varje task har ytterligare uppgifter där deras exekveringstid > än den för den gemensamma resursens tidsåtgång.
Citera
2017-03-29, 07:59
  #15
Medlem
Citat:
Ursprungligen postat av MeanME
Det gör det, men då det kombineras med villkoret att låsa en resurs så får du gärna ge en lösning för hur parallellism skulle kunna tillföra något här...
Låser du en resurs för en task i taget får du ju ett sekventiellt utfall per se.

Det du får göra är att dela upp de tasks som kommer in och se om du kan urskilja olika tasks som använder sig av helt oberoende resurser och slussa in dem i olika köer som jag skrev.
Dessa köer kan du då parallellköra mot varandra.

Du kan evt parallellköra varje tasks uppgifter.

Men sköta köerna som delar resurser sker bäst asynkront eller helt sekventiellt.
Och visst det finns metoder som du antyder:
De (MS) ger en timeout metod för att förhindra deadlocks vill jag minnas...
Det ger ju att du är tvungen att sätta olika timeout tider på ett antal nS för de olika trådarna som bromsar kön vid varje exekvering...

Känns ju inte så vettigt att göra då utfallet likt förbaskat blir sekventiellt och nu med en fördröjning dessutom.

Den vettigaste lösningen är just att designa det hela så det inte uppstår deadlocks över huvud taget.
Och då är det ett sekventiellt utfall från köerna som kommer vare sig TS söker något annat eller ej.

Du kan jobba runt det hela genom att utföra en analys av trafiken och komponera en resurshanterare som har en kö som den betar av asynkront för att förhindra ett stop och deadlocks vid varje task och bara få det vid intervallet av kölängden av resurshanteraren det kan räcka om du har tur men då kan du ju i de flesta fall lika gärna köra all köhantering asynkront redan från början.

I de fall detta funkar är ju ifall varje task har ytterligare uppgifter där deras exekveringstid > än den för den gemensamma resursens tidsåtgång.
Om resursen är en skrivare, så kommer man alltid måsta hantera just den resursen sekventiellt eftersom skrivaren inte kan spruta ut papper för flera olika utskrifter samtidigt.

För andra typer av resurser däremot så kan resursen ha "flera klipp" som gör att det går att samköra flera jobb för just den resursen. En kommunikationsserver t ex kan ha flera worker threads som kan hämta ut jobb från en och samma kö. Vid låg last hinner ingenting köa upp så bara en tråd åt gången lyckas hitta jobb. Vid högre last finns hela tiden många klienter köade varför flera trådar kan hitta klient-jobb att utföra. Om sedan klientjobben i sin tur förbrukar en gemensam resurs (t ex ett enda koppel mot en databas) eller kan få sina jobb utförda helt oberoende av varandra kommer sedan att avgöra om dessa arbetstrådar kan utföra hela arbetet utan vidare synkronisering, eller om det finns ytterligare punkter där de kan fastna på resurslås.

Det blir alltid kapabiliteten hos de olika resurserna som sätter gränsen för det bästa man kan lyckas med. Därför man först behöver rita upp sina beroenden innan man tittar på sin design. En generell debatt kan bara prata om vilka primitiver som finns tillgängliga för att köa eller resurs-synkronisera.
Citera
2017-03-29, 09:15
  #16
Medlem
MeanMEs avatar
Citat:
Ursprungligen postat av cellplast
Om resursen är en skrivare, så kommer man alltid måsta hantera just den resursen sekventiellt eftersom skrivaren inte kan spruta ut papper för flera olika utskrifter samtidigt.

För andra typer av resurser däremot så kan resursen ha "flera klipp" som gör att det går att samköra flera jobb för just den resursen. En kommunikationsserver t ex kan ha flera worker threads som kan hämta ut jobb från en och samma kö. Vid låg last hinner ingenting köa upp så bara en tråd åt gången lyckas hitta jobb. Vid högre last finns hela tiden många klienter köade varför flera trådar kan hitta klient-jobb att utföra. Om sedan klientjobben i sin tur förbrukar en gemensam resurs (t ex ett enda koppel mot en databas) eller kan få sina jobb utförda helt oberoende av varandra kommer sedan att avgöra om dessa arbetstrådar kan utföra hela arbetet utan vidare synkronisering, eller om det finns ytterligare punkter där de kan fastna på resurslås.

Det blir alltid kapabiliteten hos de olika resurserna som sätter gränsen för det bästa man kan lyckas med. Därför man först behöver rita upp sina beroenden innan man tittar på sin design. En generell debatt kan bara prata om vilka primitiver som finns tillgängliga för att köa eller resurs-synkronisera.
Men nu verkar det inte vara för den typen av resurser som kan hantera köer TS efterfrågar en lösning till då han går i banorna om all låsa resursen för sin task och begagna sig sig av semaforer eller hur?

Återstår gör den lösningen jag gav att de köer som har skilda resurser kan köras parallellt medans de köer som begagnar gemensamma resurser som måste låsas får köras asynkront eller rent sekventiellt för att undvika deadlocks.

De uppgifter som kan köras parallellt de är ju inga problem.
De skickar man ju vidare direkt.
Citera
2017-03-29, 09:29
  #17
Medlem
Citat:
Ursprungligen postat av MeanME
Men nu verkar det inte vara för den typen av resurser som kan hantera köer TS efterfrågar en lösning till då han går i banorna om all låsa resursen för sin task och begagna sig sig av semaforer eller hur?

Återstår gör den lösningen jag gav att de köer som har skilda resurser kan köras parallellt medans de köer som begagnar gemensamma resurser som måste låsas får köras asynkront eller rent sekventiellt för att undvika deadlocks.

De uppgifter som kan köras parallellt de är ju inga problem.
De skickar man ju vidare direkt.
Saker som ligger i en kö kan i sin tur vara beroende av flera samtidiga resurser för att kunna utföras, varför du kanske inte kan ha flera arbetstrådar som poppar uppgifter - den första arbetstråden kan nämligen låsa en eller flera kritiska resurser som gör det meningslöst att ha ytterligare en worker-tråd.

Men trådskaparen har inte visat någon form av relation mellan sina resurser på ett sätt som gör det möjligt att prata lite mer specifika möjligheter.
Citera
2017-03-29, 13:52
  #18
Medlem
Trillskes avatar
Alltså, MS TPL har sjukt bra stöd out of the box för trådade applikationer. Med hjälp av task/async blir det en barnlek för enkla tillämpningar.

Testa att mäta följande upplägg:
Citat:
Task.Run(() => alg1());
Task.Run(() => alg2());
Task.Run(() => alg3());
Task.Run(() => alg4());
Task.Run(() => alg5());

Task.Run(() => alg1()).ContinueWith(() => alg2()).ContinueWith..... ... ...;
Där alg är helt godtyckliga algoritmer.

Och nej, concurrency är inte meningslöst bara för att vi inte processar parallellt. Skrivaren var ju ett oerhört bra exempel eftersom det antagligen innefattar både intern logik samt något service call och väntan. Vi kommer då promenera mot skrivaren concurrent med att utskriften görs - även om vi inte kan hantera skrivaren och gå samtidigt, utan alternerar mellan att gå och att hantera skrivaren.

Så det är nog bra om man håller isär det. Nästan alla tillämpningar: TPL, relativt enkelt.
Väldigt speciella tillämpningar (exempelvis specifikt hantera just parallellism, d.v.s. explicit dela upp arbete på olika kärnor snarare än bara olika trådar): jobbigt.
Citera
2017-03-29, 14:15
  #19
Medlem
Sane?s avatar
Jag kan rekommendera http://hangfire.io/. Har själv använt det för ett större projekt hos en kund.
Citera
2017-04-01, 20:09
  #20
Medlem
Läs om RX

Edit: dett kanske är något för dig: https://www.codeproject.com/Articles...llelism-in-NET
Citera
  • 1
  • 2

Stöd Flashback

Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!

Stöd Flashback