> > Mit if !(system.timer() % 10) yield(); an Anfang des Threads wird der Thread nur alle 10 ms ausgeführt
> > und sonst die Kontrolle an das OS als an die Threadfunktion für die Glove-Auswertung abgegeben.
>
> Das ist nicht ganz richtig.
> Diese If-Anweisung sorgt dafür, da� genau einmal ein Threadwechsel ausgeführt wird
> Der Thread wird aber auf jeden Fall öfters ausgeführt. (Wie oft, ist abhängig von der Anzahl
> der Threads, der Prioritäten und der Art der ausführenden Anweisungen.)
Ã?h.. Sekunde... wenn ich das richtig sehe, wird ein Thread neu gestartet nachdem er durchlaufen wurde.
Wird ein Thread 1000 mal pro Sek durchlaufen, wird er auch 1000 mal neu gestartet.
Setze ich diese (meine) Abfrage an den Anfang, so wird doch so oft mit yield; an andere Thread abgegeben bis
timer % 10 einen graden Wert ergibt, also 10 ms um sind.
Bei einem Thread der 1 Sek. läuft bis er neu gestartet wird, nutzt das natürlich kaum was.
Evtl. wäre daher ein Wert wie timer % 50 oder timer % 25 besser... das müste man dann ausprobieren.
Aus Deiner Darstellung lerne ich, das yield für das Tasking nicht gleichzusetzen mit einem break einer
for-Schleife ist. Das dachte ich bisher nämlich. Wenn yield nur eine "Unterbrechung" verursacht, und keinen
Threadwechsel, dann sieht das natürlich anders aus. Ich hatte das Handbuch allerdings so interpretiert.
> Wenn also irgendwo
> thread xyz
> {
> if !(system.timer() % 10) yield;
> ...
> ...
> }
> steht, wird ein yield zwar einmal die Prio abgeben, jedoch wird der folgende Code
> auf jeden Fall ausgeführt, auch wenn noch keine 10ms vergangen sind.
> Auch wird sicher dieses yield; in mind. 95% der Thread-Durchläufe ausgeführt,
> da die Wahrscheinlichkeit, daÃ? der Timer zu diesem Zeitpunkt einen durch 10 teilbaren
> Wert hat, sehr gering ist.
> Eine funktionierende Alternative wäre:
> long timer;
> thread xyz
> {
> timer=system.timer()
> loop
> {
> wait system.timer()-timer>=10;
> timer=timer+10;
> ...
> ...
> }
> }
>
Ok.. das ist dann evtl wirklich besser.
Ich habe mein Vorschlag nicht vorher ausprobiert, mir ging es zunächst nur um die konzeptionelle Idee
um zu verhindern das der Tread Rechenleistung frist obwohl dies nicht zwingend notwendig ist.
Für die praktische Umsetzung mag Dein Vorschlag mit wait system.timer()-timer>=10; besser funktionieren.
> Man könnte auch einfach mit sleep 10 arbeiten. Jedoch kommen hier bei Multithreading
> meist Laufzeiten von etwas mehr 10ms raus.
> Wenn es also nicht auch "exakt" 10ms ankommt, sollte man mit sleep arbeiten.
Auch das ist ne Idee.... warum in die Ferne schweifen wenn das Gute liegt so nah... :-)
Die Grundidee, den Steuertask auszubremsen um Rechenzeit für einen zweiten Task zur Datenerfassung
zu bekommen ist davon aber nicht in Frage gestellt, und darum ging es mir ja eigentlich.
Ich denke, Fischi sollte beides mal ausprobieren ... Deinen Singlethreadansatz und meinen Multithreadansatz
und dann sehen womit er besser zurecht kommt. Spätestens wenn er noch mehr Aufgaben mit der CC2
zu erledigen hat, wird er auf Multithreading umsteigen... Aber das ist auch ne Philosophiefrage... :-)
GruÃ? Rolf
Antwort schreiben
Antworten:
Re: hwcom sync-Probleme? (von Rolf - 5.08.2003 13:25)Re: hwcom sync-Probleme? (von Fischi - 5.08.2003 13:45)