err, folgendes Problem:
Ich check einfach nicht wie Threads funktionieren.

Wenn ich bei 'ner Komponente im Hintergrund statt TTimer nen Thread laufen lassen will, wie erzeug ich den, setz nen Interval (??? oder sowas), usw...

In der Hilfe steht nur was von Programm->ThreadObjekt oderso

Ist Thread überhaupt sinnvoller als Timer?

Moderiert von Tino: Titel geändert.

Hi,

das sind 2 verschiedene Dinge ein Timer ist ein Zeitgeber, der in bestimmten Abständen Anweisungen ausführt. Ein Thread ist ein separater Prozess, der im Programm parallel abläuft, und da gibt es auch kein Intervall.

Wenn Du dein genaues Vorhaben postest kann man Dir besser helfen.

MFG

- Ernesto -

Allgemein gesagt möchte ich bei einer Komponente in einem bestimmten Abstand eine procedure aufrufen.

Dann denk ich mal, dass du mit einem Timer besser beraten wärst. GetTickCount wäre auch eine Möglichkeit. GetTickCount liefert dir in millisekunden, die nach Rechnerstart vergangen sind. Da könntest Du in einer Schleife eine Formel als Bedingung aufsetzen und somit auch dein Ziel erreichen. Evtl. noch Application.ProcessMessages in die Schleife einfügen, damit das Programm nicht einfriert.

MFG

- Ernesto -

Hallo,

ErnestoChe hat folgendes geschrieben:

Evtl. noch Application.ProcessMessages in die Schleife einfügen, damit das Programm nicht einfriert.

das währe nicht nötig wenn diese Schleife in einem Thread läuft. Ein Timer ist allerdings einfacher.

Tweafis hat folgendes geschrieben:

Ist Thread überhaupt sinnvoller als Timer?

Ein Thread ist dann sinnvoller, wenn die Timer Aktion aufwändig ist (komplizierte rechnungen) und wenig mit den Eigentlichen Programm Komuniziert werden muss (denn wenn du z.B. aus einem Thread ein Label ändern willst, muss erst der Thread mit deinem Programm Syncronisiert werden. Auch sind Treads sinvoll, wenn du erwartest, dass dein Programm in einer Multiprozessor Umgebung eingesetzt werden, denn dan kann der Thread auf einem anderen Prozessor laufen als der Rest des Programmes.

Gruß
Klabautermann

Klabautermann hat folgendes geschrieben:

das währe nicht nötig wenn diese Schleife in einem Thread läuft. Ein Timer ist allerdings einfacher.

Hab ja auch gar nicht gesagt, dass es das im Thread machen soll

Naja, dann nehm ich lieber nen Timer, das hört sich kompliziert an und warum kompliziert wenns auch einfach geht?

Wenn du etwas über Threads erfahren willst und wie man sie korrekt ohne die Thread-Klasse der VCL implementiert, dann kuck mal hier: Threads mit Delphi - Ein Crashkurs.

Willst du einen Thread für eine bestimmte Zeit ruhen lassen, bau ein sleep ein.

Kann ich den Thread einfach mit sleep schlafen lassen ?? also ohne ProcessMessages und so? und das ändert nichts an der hauptapp?

Das ist ja gerade der Gag bei Threads, sie laufen quasi parallel zum Hauptthread mit deinem Fenster. Ich dachte das wäre in meinem Text deutlichgeworden.

Ehrlich gesagt hab ich ihn nur überflogen und die DemoApp angeschaut.
^^

Kleine Babies kleine Kinder reagieren auch bevorzugt auf Bewegeung.

Luckie hat folgendes geschrieben:

Kleine Babies kleine Kinder reagieren auch bevorzugt auf Bewegeung.

Lol, was soll das bitte bedeuten???

Na ja, bei dem Demo passiert / bewegt sich doch was. Und darauf scheinst du ja reagiert zu haben.

Achso

Aber hören wir auf hier rumzuspammen

Bei 3050 Posts macht das eine Post mehr oder weniger auch nicht mehr viel aus. Aber du hast recht, es wird off-topic.

Hi,

2 kleine Infos noch

1.) Wenn im Timer etwas aufwendiges geschehen soll, würde ich einfach im Timer den Thread starten.. Also Thread.Execute Das sollte in den meisten fällen ausreichen.

2.) Zu der sache mit Multiprozessoren... Wenn man Threads darauf auslegt das sie auf MP Systemen laufen, hat man viel arbeit... Ich weiß nicht in wiefern die sicherheit in der VCL Version schon drin ist, aber als ich für mein Snake3D einen Thread für die bewegung benutzt habe (in NonVCL), gab es laufend BlueScreens bei mir
Denn, das Spiel und der Thread liefen auf getrennten CPUs.. und wenn nun das Spiel auf z.B. die X-Position der Schlange zugreifen wollte, und diese im selben moment von dem Thread geändert wurde.. peng..
BlueScreen, NMI Parity Error.. (unter Win2k!)

Und da man nie sicher sein kann, das ein Programm nicht auchmal auf nem MP System läuft, sollte man immer gut überlegen wie man seine Threads aufbaut, und nach möglichkeit nie einen Wert im Thread verändern auf den gerade zugegriffen werden könnte.

Au'revoir,
Aya~

Bei mir wäre das lediglich in dem Timer eine aktualisierung einer Variable auf die aktuelle Uhrhzeit und eine RePaint...

Ihr habt mich überzeugt, da lohnt sich wirklich kein Thread. Zumal das viel komplizierter ist

Benutz ich halt weiterhin nen Timer ^^

Aya hat folgendes geschrieben:

[..] und wenn nun das Spiel auf z.B. die X-Position der Schlange zugreifen wollte, und diese im selben moment von dem Thread geändert wurde.. peng.. BlueScreen, NMI Parity Error.. (unter Win2k!)

Eh klar.. aber das ist nicht nur auf MP Systemen so sondern kann dir auch auf einem ganz normalen Single Processor System passieren! Aber genau aus diesem Grund gibt es ja auch diverse Synchronisations-Mechanismen!
CriticalSection, Semaphore, Mutex, ....

Ganz richtig ... mit einer Einschränkung.
Ich habe nämlich gehört, daß viele Teile von Delphi (7) threat-sicher sind - allerdings mit Einschränkungen. Bestes Beispiel ist threatvar - wenn du das Ding auf einem MP einsetzt kannst du zirka 10.000 mal schneller eine Zugriffsverletzung errreichen als auf SP-Systeme.
Ähm - Frag mich nicht warum - ich habs selber gelesen.

Ach ja - der Autor hatte da so einen geilen Satz:

Delphi stammt aus einer Zeit, als PCs noch einen Prozessor hatten, MS DOS nur einen Prozess unterstützte, 16 Bit statt 32 Bit, Borland noch Borland war, Männer noch Männer und threat-Programmierung kein Thema. *g*

Wie dem auch sei - wenn man sich unter Delphi auf die bordeigenen Synchronisationsmittel verläßt hat man schneller Probleme als man denkt - da ists schon besser selber was zu basteln.

Ach ja - ich rede hier ja auch von Poweranwendungen - für normale kleine Progrämchen (unter 1. Mio Zeilen Code), ists wurscht - und sooo kompliziert ists ja nicht - ich habe meine Multitasking-Angst seit dem Amiga schon lange überwunden *g* - und ich fürchte mich auch nicht mehr vor Lederhosenträgern Man kann mit beiden ganz unkompliziert umgehen.