Tilbakemelidinger på multithreading ide

[Giddion]

Jeg kom på en ide om en rimelig enkel og forhåpentligvis bra system for å styre n antall threader til n antall jobber. Så jeg hadde håpet å få tilbakemeldinger av alle typer..

 

Teknikken går utpå at man har en array av jobb() funsjoner... og threadene vandrer gjennom denne dvs når man er ferdig med en jobb så ser man på en taller hvilket jobb array nr som ble sist tatt, så teller man en opp (++) så starter man på den jobben.

 

dette forutsetter at jobbene ikke trengs utføres i en fast rekkefølge og krangler med hverandre.

 

takker for alle svar.

[Dead_Rabbit]

Har du testet dette, eller er det foreløpig bare en idè?

[Giddion]

Har du testet dette, eller er det foreløpig bare en idè?

6036733[/snapback]

 

Bare en ide.

[einaros]

Det du vil lage er en ThreadPool-implementasjon, med en finurlig kø-mekanisme, slik at alle jobber blir tildelt plass basert på parameter som blant annet prioritet og maks levetid (sykehusprinsippet).

[DarkSlayer]

Er vel slik java sin threadpool fungerer .... grovt.....

[Giddion]

Det du vil lage er en ThreadPool-implementasjon, med en finurlig kø-mekanisme, slik at alle jobber blir tildelt plass basert på parameter som blant annet prioritet og maks levetid (sykehusprinsippet).

6037015[/snapback]

 

hmm... sånn som det ser ut nå har jeg ikke tenkt på noen spesiel kø mekanismer, det er rett og slett en array med jobber som vil loope (gjemte å si det tidligere) så når en thread kommer til enden så starter den på 0 igjen. Jeg har planer om å implimentere den i et spill så oppgavene vil være som regel være statiske, men treger ikke å være det, metoden gjør det enkelt å sett inn threader i runtime og kan på den måte tilpasse seg antall CPUer i systemet. Men det er helt klart at en eller annen form for køsystem og prioritering må implimenteres.

 

takker for alle svar.

Endret 4. mai 2006 av Giddion

[Klette]

Hmm, husk at i spill så er det kjekt å vite hvilken rekkefølge ting skjer i . (Du vil f.eks ikke tegne framen før A.I.'en har oppdatert seg osv.

 

Men, whatever rocks your boat.. Prøv og finn ut om det funker bra

[Giddion]

hmm... det er så farlig på mange ting.. som fks lyd, nettverk (til en vis grad), AI, disk lesing. Hvis man da har en god fps. Men da tror jeg har hørt nok til å starte full implimentering i koden. Men det vil ta en stund før jeg får realistiske resultater .

[Ole_Brumm]

Hvorfor tror du at du kan gjøre dette bedre en scheduleren i OS'et ditt? Med andre ord; hvis du har N tasker, hvorfor bruker du ikke bare N tråder (istedet for M tråder med fancy(?) schedulering-kode)

[Giddion]

Vel det enkleste hadde jo vært å brukt n tråder, men hvis det er fks 30 tasker, så tror jeg ikke det er spesielt lurt av meg å opprette 30 tråder ettersom det kan dra mye cpu kraft, og desuten kan det ikke lett skaleres opp i runtime. Jeg tror rett og slett jeg har mer igjen for å ha så få threder, og det er også det jeg har sett på lignende prosjekter.

 

Mange av oppgavene er veldig små, som fks skjekke lyd bufferen og eventuelt lese på disken etter mer. Jeg syntes det blir fryktelig mye å opprette en egen tråd til å gjøre dette, overheaden ved task switching blir nok mye større enn andre metoder.

 

Men det er tatt til ettertanke og det spør om jeg ikke tester ut din(Ole_Brumm) metode også siden den er relativt enkel å implimentere.

[Klette]

Bare husk å ikke bruke threads kun for å bruke det. Bruk de smart, og der det er nødvendig. Var forrersten noen presentasjoner fra GDC2006 du burde ta en titt på vedrørende dette (tror det var 2006 i hvertfall

[Giddion]

Jeg har lest på 2006-GDC-NV_Multi-Thread-Best-Practices.pdf som jeg fant hos nvidia. Er det den du tenker på?

Jeg hadde tenkt å bruke 2 tråder ved 1 CPU: 1 til windows beskjeder(pga 60 fps sperre) og lyd og en annen tråd til resten.

[Arne]

Eg forstod ikkje heilt kva du skulle bruke programmet til, kan du forklare det korleis det vil vere i praksis?

[Klette]

http://en.wikipedia.org/wiki/Game_engine