[ALG] Threads

[Verwijderd]

Hoi,

Ik moet een apparaat programeren met 8 seriele poorten. Aan deze poorten zitten displays met adressen van 0x0001 tm 0xFFF0 oftewel er zijn 65520 mogelijk adressen op iedere poort.

Ik moet helaas serieel zoeken, dit zorgt ervoor dat het 20 minuten duurt om 1 poort uit te lezen. Nu beweerde de hoofd sotfware engineering hier, dat als ik dit dmv threads zou doen, ( dus 8 threads ( 1 tje per poort)) dat het sneller zou zijn dan 8 keer een aanroep van een functie die dit doet.

Maar volgens mij is dit onzin. Het is namelijk zo of je nu 8 processen ombeurt een timeslice geeft.

voorbeel de functie die de thread runt duurt 20 minuten dus --> 8 x 20 min = 160 min

of je doet het met threads, iedere thread krijgt een timeslice van 20ms iedere thread heeft dan (20*60*1000)/20=60000 slices nodig om de functie te voltooien

nou dit dan 8 keer 8*60000=480000 slices van 20 ms

480000*20=9600000 ms in totaal -->9600000/1000/60 = 160 min

het is toch alleen handig als je iets hebt wat om de 5 seconden moet pollen ofzo terwijl de andere processen ook door lopen of heb ik het nu mis ( of als je systeem ff moet idle in een proces, dat dan een ander proces tijd krijgt) maar voor mijn toepassing is het toch helemaal niet handig? of vergis ik me nu

[pjvandesande]

Bij het uitlezen is je processor toch niet 100% bezig continue. Ik zou eigelijk zeggen test het gewoon zelf even.

[The_Ghost]

Ik denk dat jij hier ongelijk hebt; de vertraging zit waarschijnlijk in de poorten. Als je threads gebruikt kunnen die rustig opdracht geven tot het doen van een actie op de poort, en vervolgens gaan slapen, zodat een volgende thread aan het werk kan.
Dit kan je behoorlijk wat tijd schelen natuurlijk..

[Verwijderd]

Ja maar als ik het probeer, en ik zet er een printf in met het poortnummer wat hij afzoekt lijkt het toch redelijk serieel te gaan

[The_Ghost]

jewel; maar je kunt wel 8 poorten tegelijk afzoeken...
Op die manier kun je toch 8x seriëel zoeken tegelijk? Mits de rest van je systeem hierbij geen botlleneck vormt moet je toch een aardige winst kunnen boeken toch?

[Verwijderd]

Ik denk dat het systeem wel de bottleneck is. het is namelijk een communicator device --> met een 266mhz cpu (een of andere vage pico cpu)

[farlane]

Verwijderd schreef op woensdag 01 december 2004 @ 11:19:
Ik denk dat het systeem wel de bottleneck is. het is namelijk een communicator device --> met een 266mhz cpu (een of andere vage pico cpu)

Met dat monster kun je behoorlijk wat serieele porten pollen zonder dat het systeem de bottlenk wordt.

[The_Ghost]

dat lijkt me wel ja;
Het kan natuurlijk zijn dat de functies die je gebruikt om die adressen na te kijken wat krommer in elkaar steken dan dat wij hopen. (Ik neem ff aan dat die uit een bestaande lib komen oid)
Normaal zou je de opdracht geven, je thread laten slapen tot er antwoord is en dan verder gaan (volgende opdracht geven).
Als thread 1 dan slaapt kan thread 2 opdracht geven aan de andere poort enz...

Als de functies die je gebruikt blocking reads doen, blijft jouw thread net zo lang wachten tot er data terug is. Dan werkt dit geheel niet nee.

[Verwijderd]

nee zo werkt het niet mijn code ziet er zo uit:

code:

void *searchDisplays(int handler, int arrayNr)
{
   int i, hulp;
   unsigned int adres;
   unsigned char buffer[8];

   adres = 0x0001;

   buffer[0] = CMD_DISP1_SET_ASCII;
   buffer[1] = 'F';
   buffer[2] = 'o';
   buffer[3] = 'u';
   buffer[4] = 'n';
   buffer[5] = 'd';
   buffer[6] = ' '; 

   for(i=0;i<65520;i++)
   {
       writePacket(handler, adres, buffer, 7);
       uSleep(12000);
       hulp = read(handler, &rBuf, sizeof(rBuf));
       hulp = read(handler, &rBuf, sizeof(rBuf));
       hulp = read(handler, &rBuf, sizeof(rBuf));
       
      if ( rBuf[0] != '<')
      {
          switch(arrayNr)
          {
               case1:...
          }
      }
     adres++
    }
}

Ik heb nu ff het vullen van de arrays dmv van cases weg gelaten en nog wta dingen die niet van belang zijn. die usleep is nodig omdat ik anders niet kan lezen wat op de lijn staat

[H!GHGuY]

voor zover ik je bedoeling begrijp zou deze code er redelijk wat sneller op gaan...

want in de tijd van je usleep kunnen de andere threads hun werk doen...

stel dus dat de totale verwerkingstijd van je computer verwaarloosbaar is tov van de tijd die je display nodig heeft, dan kun je 1 volledige 'cycle' doen in de tijd die 1 display nodig heeft.

of serieel voor de processor (theoretisch volgens een ideaal systeem)
thread 1-8 allemaal writepacket (serieel en in volgorde) << tijd verwaarloosbaar
thread 1-8 allemaal usleep voor dezelfde tijd << duurt langst...
thread 1-8 allemaal verwerking/opvragen van read() << tijd verwaarsloosbaar

sommetje: die usleep duurt dus het langst en dus zul je de totale tijd nodig hebben die 1 display nodig heeft om alle 8 de displays aan te sturen.

[LordLarry]

Theoretisch zijn threads altijd langzamer, want het kost de processor en het os ook tijd om te switchen tussen de threads. Maar zodra de threads acties moeten uitvoeren waar een vertraging in kan ontstaan kunnen threads sneller zijn als zonder threads. Ze hoeven namelijk niet op elkaar te wachten.

[MrSleeves]

Euhm.. die uSleep begrijp ik eigenlijk ook niet echt.
Ik heb een communicatieclass die functies uit kernel32.dll gebruikt.
Ik lees en schrijf naar de COM-poort m.b.v. 2 threads. Eén voor het lezen en één voor het schrijven. Bij het schrijven wordt data klaargezet en wordt de thread "geschopt", die de buffer dan verstuurd.

De leesthread kan ook geschopt worden en die gaat dan proberen te lezen. Dat kan dus wel even duren. Als er resultaat is, wordt dat bij de ingelezen buffer gezet en die wordt ingelezen als dat nodig is.

Gaan slapen is ook best kort door de bocht. Want wat gebeurt er als de andere kant van de lijn te laat reageerd? Of heb je zo'n lange tijd genomen dat dat nooit voorkomt (dat betekent dat die sleep bijna altijd veel te lang is)?

[Verwijderd]

kort en kracht ja de sleep is te lang (dus lang genoeg)

Ik krijg het niet beter voor mekaar eigenlijk

Maar hij geeft zowiezo een segementation fault zodra de 2de thread wil gaan runnen :S:S

[abeker]

Zoals het nu is, is die usleep inderdaad een grote bottleneck. Deze neemt 65% van de tijd in beslag. Dat betekent dat het 7 minuten kost om alle adressen op een poort te controleren als je geen usleep nodig zou hebben. Dit vind ik zelf nog steeds erg veel tijd.

Je hoeft geen meerdere threads te gebruiken om alle poorten te controleren. Je kunt ook alle poorten in 1 lus controleren, zoiets als:
-schrijf naar poort 1
-schrijf naar poort 2
-enz...
-usleep
-lees van poort 1 + verwerk gegevens
-lees van poort 2 + verwerk gegevens
-enz...

Dit zou dan ongeveer 8*7 + 13 = 69 minuten kosten, ipv 160 minuten.

Nog een paar losse opmerkingen:

• Is er niet ergens gedocumenteerd hoeveel tijd er moet zitten tussen die leesactie en die schrijfactie?
• Moet je echt 3x lezen?
• De variabelen i en adres hebben in principe toch dezelfde functie?
• afhankelijk van de manier waarop rBuf is aangemaakt, geeft sizeof(rBuf) de lengte van de string terug òf de grootte van de pointer.

[Verwijderd]

abeker>

• Dat is echt een goed idee dat ga ik even proberen.
• nee er is niet gedocumenteerd hoeveel tijd er tussen zit. Ik zet data op de lijn, de betreffende display waarvoor dit bedoeld is, haalt dit op. vervolgens geeft hij een reactie erop.
• Dat drie keer lezen is voor de zekerheid, als ik dit niet doe dan mist hij soms data
• ja de variabelen i en adres hebben dezelfde functie, alleen als ik die for loop wil laten lopen dmv die hexadecimale waarden krijgt ik fouten (heel vreemd)
• met die waardes die gelezen worden wordt eigenlijk niets gedaan dus het maakt niet zoveel uit wat rBuf doet

[Verwijderd]

Met deze code vind ik 20 minuten eigenlijk nog heel snel.

Je hebt 65520 mogelijkheden en wacht 12 sec. Als er een apparaat aan een port zit vind je die na 32760 pogingen * 12 seconden = 6552 minuten

Iets zegt me dat dit niet effectief is.

[The_Ghost]

hmm usleep werkt op de meeste platforms toch echt in microseconden.. dat scheelt een stukje..

[Verwijderd]

met de manier die hier boven beschreven is loop het als een trein!!! 20 min voor 8 poorten! ff checken of de usleep nog minder kan

[Verwijderd]

The_Ghost schreef op woensdag 01 december 2004 @ 14:49:
hmm usleep werkt op de meeste platforms toch echt in microseconden.. dat scheelt een stukje..

Volgens mij moet ik ook maar eventjes gaan slapen

[Verwijderd]

hgahah ja teruste en doe katrien de groeten van me

[MSalters]

Threads zijn in principe alleen maar een simpele methode van programmeren. Wat jij hier doet kan altijd, en kan altijd net zo snel zijn als een threaded oplossing. Pas op het moment dat er I/O functies beschikbaar zijn specifiek voor threads kan het sneller zijn om die te gebruiken.

[MrSleeves]

Verwijderd schreef op woensdag 01 december 2004 @ 15:01:
met de manier die hier boven beschreven is loop het als een trein!!! 20 min voor 8 poorten! ff checken of de usleep nog minder kan

Als je de sleep lager maakt, loop je wel het gevaar dat je informatie mist.
Kan je niet een thread maken die op de poort luistert (elke 100 ms ofzo) en alsie wat binnenkrijgt, buffer je dat. Als een andere thread dan klaar is om de ontvangen info te verwerken, checkt die thread of alles binnen is en doet de verwerking. Ook geen gevaar dat je iets mist.

Ik weet niet wat voor systeem je gebruikt, maar kan je geen broadcast bouwen? Op adres 0x000 of 0xFFFF ofzo, waarmee je aangeeft dat alle apparaten moeten replyen ofzo. Ik denk dat 65000x8 displays toch vrij onwaarschijnlijk is.

[Verwijderd]

dit kan dus niet, op een broadcast geven de displays geen reply!! echt heel vervelend.

Er hangen idd maar max 255 displays op 1 poort in verband met de beperkingen van de Rs485 IC

Ik ben hier stagiair en als ik de displays had geprogrammeerd had ik daar rekening mee gehouden maarja, voor de gene die het interessant vinden, dit is de module

[farlane]

Voor deze code zijn threads absoluut niet nodig (wel een read met timeout of een nonblocking read/select), en die uSleep ook niet.

Anywayz, tenzij de displays een heel slim protocol hebben kunnen ze natuurlijk niet reageren op een broadcast.