Threads VS Listen
Übersicht
Sonstiges Smalltalk
|
StarwarBetreff: Threads VS Listen |
 Di, Dez 08, 2009 18:43Antworten mit Zitat 
|
|---|---|---|
|
Hallo,
Ich habe eine Wassersimulation für den Info-Unterricht gecodet: EDIT: Mit Wassersimulation mein ich nix à la Noobody, sondern nur Kreise, die sich ausdehnen und nicht gegenseitig beeinflussen. Sieht aber trotzdem nett aus. Code: [AUSKLAPPEN] Hauptschleife:
-Bei Mausbewegung neue Kreise hinzufügen (OOP) -Liste der Kreise durchgehen -Kreis updaten -Kreis Zeichnen -Flip/Cls -Waittimer Sein Ansatz (Java): Code: [AUSKLAPPEN] Wenn Mausbewegung
Neue Kreise erstellen. Jeder Kreis bekommt einen eigenen Thread. Kreis Updatet und zeichnet sich selber. Er benutzt ein Delay (kein Prozessorstop) Sein Argument ist, dass sein Code viel übersichtlicher ist, und dass er sich um nichts mehr kümmern muss, ich dagegen die ganzen Objekte durchgehen muss. Meine Argumente sind Frameunabhängigkeit und mehr Kontrolle. Habt ihr Argumente, die für meine Variante oder für seine sprechen? MFG |
||
|
Smily |
Di, Dez 08, 2009 18:52 Antworten mit Zitat
|
|---|---|---|
|
Delay ist böse.
Wenn, dann bitte mit Timern o.ä. arbeiten. aber prinzipiell sind beide ansatzpunkte richtig und haben ihre daseinsberechtigung Grüße, Smily |
||
|
Lesestoff:
gegen Softwarepatente | Netzzensur | brain.exe | Unabhängigkeitserklärung des Internets "Wir müssen die Rechte der Andersdenkenden selbst dann beachten, wenn sie Idioten oder schädlich sind. Wir müssen aufpassen. Wachsamkeit ist der Preis der Freiheit --- Keine Zensur!" stummi.org |
||
|
|
Starwar |
Di, Dez 08, 2009 19:00 Antworten mit Zitat
|
|---|---|---|
Ich sagte ja delay ohne Prozessorstopp.  Nicht ein einfaches Basic-Delay.
Irgendwie muss ich ihn überzeugen
MFG |
||
|
Xaymarehemals "Cgamer" |
Di, Dez 08, 2009 19:05 Antworten mit Zitat
|
|---|---|---|
|
Wenn jeder Kreis nen eigenen Thread hat, wirds Windows irgendwann in die Knie zwingen, da es die Prozessorzeit einfach nicht mehr verteilen kannst(Hier ab 2400 Threads).
Deine Variante ist "Prozessorschonender" und kann auch gut und gerne mal ein paar Wochen laufen normalerweise ohne crashes. Seine Variante ist übersichtlicher, allerdings müsste man den Threads auch sagen wann er arbeiten soll. Ein andauernd arbeitender Thread mit Delay wird sich irgendwann Aufhängen, da der Speicher pro Thread begrenzt ist (leider) und da Threads erst den Speicher den sie benutzt hatten wieder freigeben, wenn das Handle geschlossen wird. Wenn seine Variante nicht für jeden Kreis einen eigenen Thread macht, dann würde ich seine bevorzugen. Immoment eher deine Variante |
||
| Warbseite | ||
|
mpmxyz |
Di, Dez 08, 2009 20:17 Antworten mit Zitat
|
|---|---|---|
|
Wie viele Wasserpartikel habt ihr denn erstellt?
Wenn das zu viele werden, gibt es nur noch irgendeine Fehlermeldung und das Programm ist aus... Diese Grenze ist bei vielen Threads auch mehr oder weniger schnell erreicht. Wie würde er denn schnell und und einfach Doublebuffering nutzen? Er kann ja nicht ohne weiteren Extracode den Partikeln sagen, wann sie berechnet und wann sie gezeichnet werden sollen. Das "man muss sich nicht mehr darum kümmern"-Argument finde ich aber ziemlich ... seltsam. Als ob es einen umbringt, statt einen "riesigen"- da muss er ja einiges implementieren und einstellen- Aufwand um die Threads zu machen, einfach das hier zu schreiben: Code: [AUSKLAPPEN] For(Particle p:list){//Ok, beim Schleifenkopf bin ich mir gerade nicht so 100%ig sicher, aber es wird nicht komplizierter.
p.Update(); p.Draw(); } So viel außerdem zur Übersicht... mfG mpmxyz |
||
|
Moin Moin!
Projekte: DBPC CodeCruncher Mandelbrot-Renderer |
||
Übersicht
Sonstiges Smalltalk
Powered by phpBB © 2001 - 2006, phpBB Group