C#: Problem med BackgroundWorker - threading

[Thomas Toget]

Jeg har en form med en knapp som starter en koverteringsjobb i en BackgroundWorker... I DoWork metoden bruker jeg en del Console.WriteLine(".."). Jeg har også omdirigert consolestream til min egen konsoll.. Problemet er at jeg ikke får lov til å kalle Console.WriteLine i DoWork metoden siden konsollobjektet mitt eies av en annen tråd... Hva kan jeg gjøre for å få til dette? :s

[Wubbable]

Bruk ReportProgress(), der du setter userstate til det du vil skrive i konsollen, også i reportprogress sub'en gjør du slik:

 

Console.WriteLine(e.UserState) (Hvis jeg ikke husker feil)

[Thomas Toget]

Der ja :-D Var i gang med å lage min egen versjon av BackgroundWorker, så ikke at jeg kunne sende objekter tilbake til hovedtråden

takk for hjelpen

[Thomas Toget]

Hmm.. Men viss jeg har lyst til at mitt konsollobjekt skal kunne ta imot kall fra flere tråder, finnes det ikke en måte jeg kan gjøre dette på? Det må jo være mulig at dersom konsollen min får to WriteLine() kall samtidig at den automatisk tar en av gangen?

[The Jackal]

lock(Console.Out)

{

Console.WriteLine("string stuff");

}

[Wubbable]

ReportProgress() kjøres på hovedthreaden, og en thread kan kun gjøre en ting om gangen...

Kjøres to stykk ReportProgress() på likt, prosesseres først den ene, så den andre...

[The Jackal]

ReportProgress() kjøres på hovedthreaden, og en thread kan kun gjøre en ting om gangen...

Kjøres to stykk ReportProgress() på likt, prosesseres først den ene, så den andre...

 

Det forsåvidt riktig, men hvis du har flere bakgrunnstråder så må du locke siden du kan få en kontekstswitch midt i metoden som skriver ut. Først og fremst et issue hvis det er flere forskjellige kall til Console i metoden som skal skrive ut ting.

Endret 4. mars 2009 av The Jackal

[Thomas Toget]

lock(Console.Out)

{

Console.WriteLine("string stuff");

}

 

Er det dette som kalles synkronisering?

[The Jackal]

lock(Console.Out)

{

Console.WriteLine("string stuff");

}

 

Er det dette som kalles synkronisering?

 

Tja...kan vel kalle det det. Det som egentlig skjer, er at objektet Console.Out blir låst for bruk når 1 tråd er inne mellom {}. Spesielt hvis man har flere kodelinjer er dette aktuelt siden man kan få en kontekstswitch før alle kodelinjene er eksekvert. I de tilfellene vil da de andre trådene som kommer til samme punkt vente til den første tråden har gjort seg ferdig før de får skrevet ut.

[Wubbable]

Går dette an for en harddisk?

Altså, at jeg har flere filestreamer, men kun en filestream får lov til å skrive til disken om gangen, for å unngå trashing.

 

Har en metode altså, men finnes det finnes en lignendes metode som består av 4 linjer med kode, tar jeg heller den

[GeirGrusom]

Du har også Mutex klassen som gjør samme jobben.

 

Mutex disk_mutex = new Mutex();

private void DoDiskWork()
{
 disk_mutex.WaitOne();

 //skriv til disk...

 disk_mutex.Release();
}

[Wubbable]

Hvis 5 threader venter på å skrive til disk, og Release() kjøres, fortsetter ikke alle 5 på likt da?

edit: Tydeligvis ikke

 

*erstatte 80 linjer med kode*

 

Forresten, det fungerer som en kø, sant?

Ingen sniking, sånn at en thread blir ståendes og bare vente fordi alle andre threader får mutexen?

Endret 9. mars 2009 av Wubbable

[GeirGrusom]

Husk at tråder kjører ikke samtidig samme hvor mangekjerner prosessoren din har.

 

Det er first-come-first-serve.

[Wubbable]

Hva mener du med det?

At de må gjennom samme bane på hovedkortet, og den er det bare en av?

 

Eller mener du noe programmeringsmessig jeg må ta hensyn til?

[GeirGrusom]

Du trenger ikke å bekymre deg for at to tråder kjører såpass samtidig at WaitOne blir kalt av to tråder samtidig, for det vil ikke skje ^^

[Wubbable]

Ja, det var ikke det jeg lurte på

Jeg mener at når en tråd kaller WaitOne(), blir den da lagt i en slags FIFO (first in first out) kø, og den får sin tur avhengig av når den kalte WaitOne()...

 

Så hvis tråd 1 gjør noe, tråd 2 kaller WaitOne(), også kaller tråd 3 WaitOne(), også blir tråd 1 ferdig, så er det tråd 2 som er neste "mann" i køen?

[HDSoftware]

Dette høres i allefall veldig logisk ut for meg. Men det er sikker mekanikk i systemet som gjør at en prosess får høyere prioritet en andre. Tipper i såfall at dette er noe du selv styrer.

 

Jeg vet i hvertfal at det er slik i Clarion og da ville det forundret meg stort om ikke det var slik i .NET også..

[GeirGrusom]

Etter det jeg vet er det ikke fifo, men first come first serve som jeg sa.

 

Statistisk sett vil alle trådene låse mutexen like ofte allikevel, så lenge de har lik prioritet. Tråder med høyere prioritet vil da også ha en større sannsynlighet for å låse mutexen enn tråder med lavere prioritet.

[Wubbable]

Hva er det som bestemmer hvilken tråd som får mutexen da, hvis de har lik prioritet?

[GeirGrusom]

Den tråden som er aktiv når mutexen blir frigjort blir den som låser mutexen på nytt.