Autor Thema: Nicht blockierendes evnt_multi  (Gelesen 16349 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline m0n0

  • Benutzer
  • Beiträge: 984
Nicht blockierendes evnt_multi
« am: Mo 05.07.2010, 23:36:56 »
Ich musste das einfach mal probieren, denn - soweit ich weiss ist der kleinste timeout wert bei einem evnt_multi 20ms ( jedenfalls ist es das bei evnt_timer laut Profibuch für den ST).

Es geht ganz einfach... vor dem aufruf zu event_multi einfach ein appl_write mit einer "Benutzerdefinierten" Nachricht schicken, schon kehrt evnt_multi sofort zurück.

pseudo C code:
/* Definition einer Nachricht,  80 ist der groesste von GEM genutzt Wert..., also sollte es ok sein 100 fuer eigene zwecke zu nutzen, wer's wissen will, muss im Kompendium schauen :) */
#define WM_USER_1 100

int app_id;
WORD mymsg[8]; /*8 WORDS = 16 bytes)

app_id = appl_init();
...

mymsg[0] = app_id;
mymsg[1] = WM_USER_1;
mymsg[2] = 0; /* keine ueberlaenge */

while( !quit)
{
 appl_write( app_id, 16, &mymsg);
 evnt_mult( ... ) ; /* kehrt sofort zurueck, EVNT_TIMER muss nicht angegeben werden, jedoch MU_MESG */
}


Es ist natürlich so, das diese Methode zur höchstmöglichen Prozessorauslastung führt solange der Prozess noch nicht vom Prozessmanager "pausiert" wurde. Ich weiss nicht genau wie relevant das auf den Multi-Tasking OS beim Atari ist... bei Windows würde diese Verfahren, sofern evnt_multi in einer endlos-schleife aufgerufen wird zu 100% prozessorauslastung führen. Aber ich glaube auf dem Atari ist das nicht ganz so schlimm, evnt_multi mit dem normalen timeout wird ja auch irgendwas in der zwischezeit machen, bevor der timeout auftritt...

Tortzdem sollte man den Prozess schlafen legen - , auf dem FreeMint system geht das mit z.B: usleep( 5*1000); für 5 ms.

Wofür man das braucht... ? Wenn man wirklich nur sehr kleine Delays haben will, bevor ein Event ausgewertet wird.

Ich zumindest finde es gut zu wissen...

Gruß,...

Offline Arthur

  • Benutzer
  • Beiträge: 10.311
  • Mein Atari erinnert mich an die gute alte Zeit..
Re: Nicht blockierendes evnt_multi
« Antwort #1 am: Di 06.07.2010, 01:00:29 »
Ist OT aber evtl. hast Du meine PN (NVRAM) nicht bekommen? Dann scheint es im Forum auch bei den PN's nicht so recht zu klappen und hängt evtl. auch hiermit zusammen.
« Letzte Änderung: Di 06.07.2010, 01:06:31 von Arthur »

Offline m0n0

  • Benutzer
  • Beiträge: 984
Re: Nicht blockierendes evnt_multi
« Antwort #2 am: Di 06.07.2010, 09:45:01 »
doch, PN ist jetzt beantwortet  ::)

gstoll

  • Gast
Re: Nicht blockierendes evnt_multi
« Antwort #3 am: Di 06.07.2010, 18:26:52 »
Leer
« Letzte Änderung: Sa 23.04.2011, 09:51:19 von gstoll »

Offline m0n0

  • Benutzer
  • Beiträge: 984
Re: Nicht blockierendes evnt_multi
« Antwort #4 am: Di 06.07.2010, 23:31:55 »
Zitat
Könntest Du mal ein Beispiel nennen? Ich versteh i.M. nicht was Du meinst.

Hallo!

Also, ich könnte es mir bei Spielen Sinnvoll vorstellen.

Normalerweise wuerde ein Aufruf von evnt_multi() maximal 20ms dauern... auch wenn man ein timeout von 5 ms gesetzt hat ( wie gesagt, Profi Buch sagt der GEM timer hat eine Auflösung von 20ms ). Wenn man Glück hat, kehrt die Funktion vorher zurueck, weil ein Event Anliegt.

Sinnvoll koennte ich es mir bei Spielen vorstellen, in der man z.b. keine Zeit mit Nichts-tun verschwenden will. (Evt. koennte man z.B, ein Animations-Frame mehr in dieser Zeit berechnen? )

Eine anderes Beispiel wäre das Abrufen von Netzwerk-Daten... eine Netzwerkkarte kann ja durchaus sehr schnell Daten liefern - ich weiss nicht ob diese Beführchtung richtig ist, aber ich könnte mir vorstellen das ein Buffer innerhalb eines Netzwerk-Stacks durchaus in 20ms voll-laufen kann, wenn man aber die Daten innerhalb der 20 ms auslesen kann, geht nichts verloren...  bzw. der Netzwerkstack muss keine Daten ablehnen.

Beispiele genug ? =)
« Letzte Änderung: Di 06.07.2010, 23:54:22 von m0n0 »

gstoll

  • Gast
Re: Nicht blockierendes evnt_multi
« Antwort #5 am: Mi 07.07.2010, 19:58:47 »
Leer
« Letzte Änderung: Sa 23.04.2011, 09:51:30 von gstoll »

Offline m0n0

  • Benutzer
  • Beiträge: 984
Re: Nicht blockierendes evnt_multi
« Antwort #6 am: Mi 07.07.2010, 21:01:27 »
Zitat
Wo steht das überhaupt mit den 20ms im Profibuch (Auflage)?


7. Auflage 1989, ich weiß das klingt jetzt doof aber ich weiß nicht wo das stand  ::) Aber der Wert klingt logisch wenn man an den 200hz timer denkt... Es wurde geschrieben das es eine Genauigkeit von 20ms gibt, und das es auch zu höheren Werten kommen kann, also es wurde die Präzision des timers beschrieben.  Für genaue Messungen also nicht gedacht.

Zitat
Wer sagt Dir, daß der evnt_multi tatsächlich immer sofort zurück kommt? Was ist wenn erst ein anderes Programm ein Ereignis bekommt.

Ich meine natürlich in der Zeit die meinem Prozess zugestanden wird. Ich dachte diese Zeit sei festgesetzt? Was kann man sonst mit dem time slice wert bei Magic / MiNT einstellen.

Zitat
Den würdest Du doch nicht mit AES Mitteln schreiben. Müßte dann es nicht jetzt schon Probleme geben?

Das ist klaro das ich den nicht mit AES schreibe... totzdem glaube ich das schnelles abholen der Daten aus dem Daten-Buffer von Vorteil ist... aber wenn auch ein evnt_timer Aufruf ohne meinen Workaround so schnell ist, dann braucht man meinen Workaround ja nicht :)

Ich werde mal messen.... Man darf gespannt sein ;)

« Letzte Änderung: Mi 07.07.2010, 21:05:09 von m0n0 »

Offline m0n0

  • Benutzer
  • Beiträge: 984
Re: Nicht blockierendes evnt_multi
« Antwort #7 am: Do 08.07.2010, 00:20:30 »
So, ich habe es nochmal auf einem MegaST mit Magic nachgemessen.

bei evnt_timer/evnt_multi sind werte unter 20 ms Sinnlos, das timeout kommt nicht früher.

Bei der Message Lösung ist das timeout ~1ms.

Offline Arthur

  • Benutzer
  • Beiträge: 10.311
  • Mein Atari erinnert mich an die gute alte Zeit..
Re: Nicht blockierendes evnt_multi
« Antwort #8 am: Do 08.07.2010, 17:20:20 »
Hier würde mich jetzt interessieren was da programmtechnisch gemacht wird wenn da kein Timer mehr benutzt wird?

gstoll

  • Gast
Re: Nicht blockierendes evnt_multi
« Antwort #9 am: Do 08.07.2010, 17:52:18 »
Leer
« Letzte Änderung: Sa 23.04.2011, 09:51:42 von gstoll »

Offline m0n0

  • Benutzer
  • Beiträge: 984
Re: Nicht blockierendes evnt_multi
« Antwort #10 am: Do 08.07.2010, 19:31:07 »
Zitat
Hier würde mich jetzt interessieren was da programmtechnisch gemacht wird wenn da kein Timer mehr benutzt wird?

Kommt halt auf das Programm drauf an, aber auf jeden Fall ist es so das man keine Prozessorzeit an einen anderen Prozess abgibt - jedenfalls nicht Freiwilig. Der Prozess wird erst unterbrochen ( und ein anderer kommt an die Reihe) wenn seine Zeit abgelaufen ist ( und diese Zeit die jedem Prozess zur Verfügung steht steht im Zusammenhang mit dem timeslice wert, den man irgendwo in Magic und MiNT einstellen kann)

Zitat
Auch mal mit null probiert? Welche Zeitscheibendauer?
Ich meinte timeslice, s.o.
0 habe ich noch nicht ausprobiert.... aber ich habe mal gelesen das solche Programme auf alten TOS versionen abstürzen ;)

Zitat
Wobei ich trotz nachdenken wieder nicht verstehe warum Du das benötigst?
Ich weiss es auch nicht! Aber jedes andere System bietet sowas doch auch :)
Unter windows wird es mit peek_message (oder so) gemacht, wobei da der unterschied ist, das der event dann nicht aus der event liste rausgelöscht wird....

Zitat
Was bringt es Dir wenn Du mal kurz in ein evnt_xxx springst?

Mehr Zeit für andere Aufgaben? Oder man kann während einer langen Rechenoperation oder einer Konvertierung oder was weiß ich, schauen ob der Benutzer eine Taste gedrückt hat, oder die Maus geklickt hat, ohne das man dadurch einen großen Geschwindigkeitsverlust hat. Mit der Timer Möglichkeit hätte man immer 20ms gewartet, und in dieser Zeit hätte man schon viel Berechnen / konvertieren können ....

Zitat
Es ist doch schon fast logisch, daß der evnt_mesag bei einer Message an
sich selbst sofort zurückkommt. Warum also dann erst überhaupt das?

Weil ich es noch nicht ausprobiert hatte und ich finde es einfach gut das es auch wirklich klappt ;)

Zitat
Ist vielleicht appl_yield das was Du in Wirklichkeit suchst?

Nein, ganz im Gegenteil - damit gibt man ja die Kontrolle an andere Prozesse ab!