Grundsätzliches zu Threads (gcc/linux/SDL)

[Nils S. (kruemeltee)]

Hi,

momentan weiss ich nicht mehr ganz so weiter. Mein Programm klemmt von 
vorn bis hinten, obwohl ich kaum Rechenleistung dafür bräuchte.
Nun bin ich schon eine ganze Weile dran und werde das jetzt mit Threads 
lösen.

Das Programm ist in C geschrieben, verwendet SDL und daher verwende ich 
auch die SDL Threads lib, da mir mit den pthreads alleine immer SDL 
abschmiert und meckert irgendwas von wegen XinitThreads. Mit der SDL Lib 
hab ich soweit keine Probelem.

Nun ergeben sich da ein paar Fragen...

Was ist eleganter/sinnvoller?
Entweder starte ich von z.B. main() aus zwei Threads. Der eine übernimmt 
die Hauptaufgaben, der andere updated mir die Ausgabe, wenn sich was 
ändert.
ODER erstelle ich nur einen Thread und lasse das Hauptprogramm 
weitermachen?

main() {
   start_thread1();  // main program
   start_thread2();  // screeen update
   for(;;) { wait_until_both_finished(); }
   exit();
}

ODER

main() {
   start_screen_updater_thread();
   for(;;) {
       // main program code here
   }
   exit();
}

Die erste Möglichkeit "hinterlässt" ja eine Endlosschleife, die 
dauerhaft Rechenleistung braucht um zu sehen, ob die Threads zu Ende 
sind.
Die Zweite Möglichkeit nutzt eben diese Schleife um die Hauptaufgaben zu 
erledigen.
Ich denke mal, da dies einmal Thread-Switchen spart, spare ich mir damit 
Rechenleistung, oder?


Das nächste:
Für die "Kommunikation" zwischen Threads,  wann wer zu warten hat, gibt 
es Mutexe.
Ist es aus Speicher/Speed-Gründen nicht sinnvoller einfach nur eine 
globale Variable zu nehmen? Speicher und Speed hab ich nicht allzuviel, 
da das Programm auf einer embedded Plattform laufen wird (64M RAM, ~2MB 
Flash frei).

int waitflag;

main() {
   for(;;) {
      do_something_on_the_screenbuffer();
      waitflag = 1;
   }
}

updater() {
   for(;;) {
      while(!waitflag);  // wait for waitflag to be 1
      copy_screenbuffer_to_screen();
      waitflag = 0;
   }
}

Oder sollte ich dabei einfach ganz auf das Warten auf ein Ereignis 
verzichten und den screen nach einer bestimmten Zeit neu aufbauen (z.B. 
50 mal pro Sekunde)?

Dann noch:
WIE warte ich in einem Thread? eine for(...;...;...) { asm("nop"); } 
oder while(!ereignis); oder einfach nur mit delay-Funktionen der 
jeweiligen Libs.
Ich möchte natürlich während dem warten keine Rechenleistung an den 
wartenden Thread verschwenden und "Stillstand" gibt es für eine CPU ja 
nicht, erst recht nicht für Pseudo-Multitasking-Sachen wie Threads.


Ich hoffe, dass mir jemand von euch das etwas genauer erklären kann.

[Sven P. (Gast)]

Ich vermute, du läufst in eine ganz typische Falle.

Hast du in deinem Programm überhaupt irgendetwas, was parallel laufen 
muss? Oder täte es nicht etwa ein Zustandsautomat?

[Nils S. (kruemeltee)]

Bisher wars der Zustandsautomat.

Es ist ja auch nicht so, dass es mit den Threads schon hängt. Ich bin ja 
gerade noch dabei, das ganze so zu planen, dass es mit den Threads 
läuft.
Momentan häng ich dran, die ganzen Funktionen Thread-Safe zu machen.

Ich möchte nur gern wissen, was mir die Performance zusammenschlägt, 
eben zum "Design" von Programmen mit Threads.

An den Threads komme ich höchstwahrscheinlich nicht mehr vorbei. Das 
Programm hat Video Ausgabe/Tastatur Eingabe, greift auch Chips am SPI 
und I2C Bus zu, simuliert mehrere IO-Bausteine und es läuft eine Shell 
drauf, die zur Laufzeit um "Binär-Packages" erweitert werden muss (bzw. 
müssen nicht unbedingt, muss aber möglich sein). Die Binär-Packages 
müssen dann auch noch von einem 8085 CPU Simulator abgearbeitet werden. 
Diese Maschinencodes sind die Programme aus ca. 250 EPROMs die noch zur 
originalen Steuerung hier rumliegen.

Soweit tut ja alles, aber es klemmt extrem an der Ausführung...

Das Teil stellt den Nachbau einer Steuerung für LED-Matrixen aus 
Waschstrassen dar, mit der aber statt nur einer wie im Original, bis zu 
8 von den Dingern gesteuert werden.