[C#]Usenet Threading

[Verwijderd]

Tweakers,

ik ben hier bezig met een usenet applicatie.

Nu ben op het punt gekomen om bestanden op te halen van de server. Alleen dat moet kunnen met meedere threads.

Dus dacht ik: ik bouw een queue met alle artikellen die ik moet downloaden, En deze queue stop ik in een threadpool. Alleen nou gaan die verdomde threads in de threadpool me kaar lastig vallen

ik het geprobeerd op te lossen met locks op de methode te zetten, maar dan blijven de andere threads in threadpool ook wachten en dat is nou niet helemaal de bedoeling.

Dus nu hoop dat hier iemand antwoord op kan geven waarom die threads elkaar lastig vallen, en wat ik hier aan kan doen.

[bigbeng]

Kalm blijven, rustig ademhalen en het dan nog eens proberen

Zou je misschien wat code kunnen plaatsen? En threads die "mekaar lastig vallen", wat bedoel je daar precies mee? Deadlocks? Verkeerd uitlezen van de queue?

[leuk_he]

Dat heet het producer consumer probleem.
b.v.

http://msdn.microsoft.com/en-us/library/yy12yx1f.aspx

Simpel gesteld maak je een queue aan waar de workers telkens 1 element vanaf halen. Alleen tijdends het eraf halen van een element van de queue lock je de queue.

[Flard]

Het idee van een ThreadPool is dat je meerdere (worker) threads gemakkelijk bij elkaar gooit en ze allemaal ongeveer even veel aan de beurt komen. Ik denk dat je dus het beste eerst bijvoorbeeld 3 downloadthreads te starten die steeds kijken of er nog iets in de Queue staat en dat vervolgens oppakken. Bij het voltooien van een downloaden zou je ze óf een nieuwe taak uit de Queue laten zoeken, óf een callback naar queue laten doen, waarop de queue weer een nieuwe thread spawnd voor een nieuwe downloadtaak. (Afhankelijk van je model / UI kun je kiezen)

[Verwijderd]

Ik bedoel met lastig vallen, ze lopen in elkaars vaarwater

als thread 1 halve wege in de methode is, en dan komt thread 2 en die begint weer vooraan in de thread, en gaat thread 3 zich er nog eens mee bemoeien en thread 4 en 5, enz. Dan krijg je een grote benden, erg gebeurd van alles, maar niet een de goede.

de stuk die de threads aanstuurt

C#:

public void Start()
        {
            System.IO.Directory.CreateDirectory(System.IO.Path.Combine(this.savepath, this.name));
            
            this.state = UsenetState.Downloading;
            
            ThreadPool.SetMaxThreads(3,0);

            foreach (UsenetQueue q in queue)
            {
                ThreadPool.QueueUserWorkItem(new WaitCallback(GrabArticle), q.articleId);
            }

            this.state = UsenetState.Completed;
        }

de methode die aangeroepen word

C#:

public void GrabArticle( object s )
        {
            string articleId = (string)s;

            System.Text.ASCIIEncoding enc = new System.Text.ASCIIEncoding();
            byte[] serverbuff = new Byte[1024];
            string filename = string.Format("{0}.dat", articleId);
            string path = System.IO.Path.Combine(this.savepath, this.name);
            int count = 0;
            byte[] downBuffer = new byte[2048];
            byte[] byteSendInfo = new byte[2048];

            //vragen om het article
            byteSendInfo = StringToByteArr("BODY " + articleId + "\r\n");
            ns.Write(byteSendInfo, 0, byteSendInfo.Length);

            //gegevens ophalen                
            while (true)
            {
                byte[] buff = new Byte[2];
                int bytes = ns.Read(buff, 0, 1);
                if (bytes == 1)
                {
                    serverbuff[count] = buff[0];
                    count++;

                    if (buff[0] == '\n')
                    {
                        break;
                    }
                }
                else
                {
                    break;
                }
            }

            response = enc.GetString(serverbuff, 0, count);

            Debug.WriteLine("READ:" + response);
            System.IO.StreamWriter sw = new System.IO.StreamWriter(System.IO.Path.Combine(path, filename));
            sw.Write(response);
            sw.Close();
        }

[bigbeng]

Klinkt als een klassiek voorbeeld van threading. Dat wil je toch ook?

Ik vermoed dat je een aantal resources deelt tussen de threads, zoals de variabele ns. Dat kan dus niet.
Als je zaken in volgorde wil afhandelen, dan moet je zorgen dat dat ook gebeurt.(en is threading dus overbodig)

Een oplossing is om GrabArticle zijn eigen connection op te laten zetten (en andere (nu shared) resources voor zichzelf aan te laten maken) met de newsserver (ik neem aan dat dat is waar ns voor is).

[ Voor 3% gewijzigd door bigbeng op 27-05-2008 18:32 ]

[Confusion]

Verwijderd schreef op dinsdag 27 mei 2008 @ 17:49:
lastig vallen

Je bent volstrekt onduidelijk. Op welke manier hebben de threads last van elkaar? Downloaden ze hetzelfde artikel, worden er artikelen overgeslagen, lopen de artikelen in de file waar je ze heen schrijft door elkaar heen, ... ?

[.oisyn]

Het idee van een threaded newsreader is idd dat ie per thread een connectie opent. Niet dat ie al die threads over dezelfde connectie gooit, wat uiteraard niet kan - een connectie wordt geopend tussen één verzendende en één ontvangende partij.

Wat jij nu hebt is dat al die threads door dezelfde telefoonlijn staan te schreeuwen wat ze willen, en die ene telefoniste op de news-callcenter er geen touw aan vast kan knopen . Terwijl als je elke thread zelf laat "bellen", ze elk hun eigen telefoniste krijgen bij wie ze hun verhaal kwijt kunnen zonder dat anderen er doorheen gaan zitten blèren.

[ Voor 4% gewijzigd door .oisyn op 27-05-2008 18:47 ]

[bigbeng]

offtopic:
/me Is jaloers
Tjeemig, ik moet ook meer met metaforen gaan gooien, want zo duidelijk als hierboven het probleem wordt beschreven...

[Verwijderd]

.oisyn schreef op dinsdag 27 mei 2008 @ 18:37:
Het idee van een threaded newsreader is idd dat ie per thread een connectie opent. Niet dat ie al die threads over dezelfde connectie gooit, wat uiteraard niet kan - een connectie wordt geopend tussen een verzendende en een ontvangende partij....

Zo had ik het nog niet bekeken, soms zoek je compleet ergens anders waar het probleem helemaal niet ligt.

Zat hier al 3 dagen op te staren

[ Voor 4% gewijzigd door Verwijderd op 27-05-2008 18:46 ]

[SH4D3H]

Verwijderd schreef op dinsdag 27 mei 2008 @ 18:44:
[...]
Zo had ik het nog niet bekeken, soms zoek je compleet ergens anders waar het probleem helemaal niet ligt.

Niet om bijdehand te doen hoor, maar waar dacht jij dan dat die threads voor waren?
Bij de meeste usenetaanbieders staat het ook aangegeven als het aantal gelijktijdige verbindingen

[RobIII]

SH4D3H schreef op dinsdag 27 mei 2008 @ 23:52:
[...]

Niet om bijdehand te doen hoor, maar waar dacht jij dan dat die threads voor waren?
Bij de meeste usenetaanbieders staat het ook aangegeven als het aantal gelijktijdige verbindingen

Jamaar, jamaar.. je hebt toch maar 1 modem?
Niet om bijdehand te doen, maar voor sommigen is het niet altijd even voordehandliggend als voor een ander. Toegegeven, in dit geval vroeg ik me ook al af of ik het probleem wel goed begreep totdat dit boven water kwam, maar toch...