Vielleicht sollte man die Aussage n bissel erweitern (abhängig von der verwendeten Architektur) :
ungefährlich isses dann, wenn nur atomare Daten gelesen werden (z.B. bis 32bit: Byte/Boolean; Word; Integer/Pointer/DWORD; ...) (einige Floats auch noch)

Sollten bspw. nich atomare Daten (z.b. auch Int64 ! und Puffer) gelesen werden, dann sind intern mehr Vorgänge notwendig. In der zeit könnte das scheduling nen anderen Thread laufen lassen, der den Puffer verändert... der andere thread liest danach nen "halb richtig-halb falsch" Puffer...

Insofern muss der eine oder andere Lesevorgang auch gelockt werden, damit dann der evtl. schreibende Thread wartet. Bzw. der lesende Thread wartet bis der andere die Resource wieder freigibt...

aber sonst tut das tut ganz gut - daumen hoch
(evtl. der vollständigkeithalber könnte man u.A. noch "threadvar" erwähnen...)

_________________
...

Erstmal vielen dank fürs lesen und für die Anregung.
Ich weiß nicht, ob ich das etwas unglücklich ausgedrückt habe oder ob du das etwas falsch verstanden hast. Was ich damit allerdings meinte ist nur reines leses (ohne irgendwelche Schreibvorgänge). Und die sind vollkommen ungefährlich.
Allerdings muss man bei Atomaren auch erwähnen. Sobald man 2 atomare Daten lesen oder schreiben will ist das auch nicht mehr atomar! Hier ist es nur sicher, dass die einzelnen Vorgang nicht unterbrochen werden. Zwischen den Vorgängen kann aber schon unterbrochen werden.

@threadvar: daran hatte ich nicht gedacht, als ich das tut geschrieben hatte. Ich habe die persönlich auch noch nie eingestzt und müsste selber erst einmal schauen wozu die gut sind.

tach,

ich hab mir auch mal das tut durchgelesen und mal mit Threads nen bisserl rumexperimentiert.
Ich hab sogar das Delphi 5 Thread Sort demo abgeschaut und teilweise verstanden.

Ich bin grad dabei nen neues System für Xenorate zu programmieren das aber diesmal auf Threads basiert da Timer mir echt auf die nerven gehn, da sie viel zu rechenintensiv sind.

Ich muss aber leider sagen, ich hab das tut nicht ganz kapiert, das einzigste was ich hinbekommen habe war das ich ne bestimmte anzahl TLabels die man vorher festlegt zur laufzeit erstellt werden und dann soviele threads erstellt werden die man starten, stoppen kann usw und die einfach ne Zahl von 0 bis 1000 hochzählen. Ist ganz interessant, bei 1000 Threads verabschiedete sich mein 1,1 GHz P3 Notebook.
auf meinem AMD 1 GHz zuhause konnte ich 10000 Threads laufen lassen ohne probleme.

<a href='http://encorex.no-ip.com/shared/Final/ThreadingTest.zip' target='_blank'>ThreadingTest.zip</a>

Naja egal...

Ich wollt eigentlich was ganz anderes wissen:

7 Threads möchte ich haben


- Einer zum berechnen und anzeigen des aktuellen Mediums. = Interval 333 MSecs. (Wird ständig aktuallisiert.)
(höheres Interval wäre mir lieber, dann würde die zeit schneller aktualliesieren und nicht mehr so rumruckeln)

- Einer zum berechnen und anzeigen des Scrolltextes = Interval 45 MSecs. (Wird ständig aktuallisiert)

- Einer zum ausfaden eines Lieds = Interval 3000 (Einstellbar) MSecs. (Wird nur einmal ausgeführt)

- Einer zum berechnen und anzeigen des OSD für Video = Interval 100 MSecs. (Wird nur einmal ausgeführt)

- Einer zum zurücksetzen des OSD für Video = Interval 2000 (Einstellbar) MSecs. (Wird nur einmal ausgeführt)

- Einer zum zurücksetzen des Statustextes = Interval 3000 (Einstellbar) MSecs. (Wird nur einmal ausgeführt)

- Einer zum berechnen und zeichnen des Analyzers, (eventuell OpenGL) = Interval 40 MSecs. (Wird ständig aktuallisiert)


Das habe ich versucht selber irgendwie zu stricken, aber leider hab ich leider nur dafür gesorgt das meine CPU stehen blieb und nen satter Bluescreen zu sehen war :,(

Ich weiss is recht kompliziert, aber sag mir mal einer wie man das besser lösen könnte ??
Im moment hab ich in Xenorate 7 Timer was mich schon tierisch ankotzt.
Das beste wäre einfach so ne Art TTimer auf Thread basis mit den gleichen eigenschaften wie Enabled, Interval, OnTimer usw.

Wer mir ne anleitung schreiben kann wie ich das realisieren könnte, den werd ich falls er es möchte in die Credits mit aufgenommen.

Ich danke für antworten,

matane,
Finalspace

1000 Threads in einer App? In der Schule wurde uns beigebracht, dass bereits 16 gleichzeitig aktive Thread ein Ein-CPU-Sys zum tote bringte... wofür braucht man 1000 Threads? D.h. Du willst 100 Dinge gleichzeitig nebenher machen, dass kann ich nicht ganz glauben. Das übelste was ich bisher je brauchte waren 3 Threads. (inklusive Haupt)

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

nunja, normalerweise sind ein paar threads kein problem - gerade laufen auf meinem system 360 Threads auf 34 Prozesse verteilt(siehe taskmanager)... Würden alle threads jetzt aber plötzlich eine beschäftigung bekommen.... reine katastrophe, ich wills mir lieber nicht vorstellen... besonders bei netzwerkprogrammen poppen oft eine ganze menge threads auf, die aber normalerweise das system kaum auslasten. 1000 Threads die richtig arbeiten ist aber wirklich heftig. und bei dir arbeiten die alle und warten nicht nur dumm(sie zählen bis 1000), dass das kein system verkraftet dürfte klar sein

Ich hab nirgends erwähnt das ich tausend brauch, da habt ihr mich falsch verstanden...
das war nur testhalber :;P

ich brauch genau 7 threads, wobei jeder unterschiedlich sein muss und einem timer ähneln sollte. Ich hab gelesen das Winamp3 z.b. auf Threads aufbaut und ausserdem als ich das Thread tut gelesen hatte dachte ich mir gleich das ich das auch in Xenorate machen kann.

Ach übrigens die Version 2.11.0.5 wartet nur darauf released zu werden, werde sie endlich heute uppen.
Wäre cool wenn mir einer bis dahin mal nen lösungvorschlag bringen könnte.
Das wird bestimmt ne leistungssteigerung von 30% oder so geben
Viele Timer können ein system total langsam werden lassen

Näheres steht oben ^

PS: Stellt euch mal ein prog vor, das beim OS start 3,7 Mio Threads startet und einfach nur ne billige zahl hochzählt... toll oda so bekommt ihr jedes OS zum abschmieren... habs ausprobiert,
Windows bringt den herrlichen Bluescreen, Linux bleibt einfach stehen.

Das ist nicht so ganz richtig. Windows raucht schon ab, wenn du über 65000 Handels erstellst. Dann bleibt das dumme ding einfach stehen ohne eine chance auf Rettung.

hm, also mein linux läuft auch mit 2500 Prozessen noch.... hab mal ausprobiert, wie man ne rechner im lan am besten lahmlegt da wurde er einfach mit ein paar pingprozessen niedergestreckt... das ergebnis: der attackierte rechner(winnt IMHO) ist komplett stehengeblieben, der linuxrechner liess sich durch ein killall ping wiederbeleben, was aber eine ganze zeit lang dauerte

Also so wie das für mich aussieht benötigst du eine ThreadKlasse die eine Interval property hat.

So und in der Execute müsstest du ein Sleep aufrufen und gleich hinherher die Dinge die du erledigen willst.

Das sollte, glaube ich, dein Problem lösen. Du erstellst dann mehrere Instanzen der Klasse und weißt den Interval und das Event zu. Schon sollte es passen. Das Sleep wartet einen Zeitraum in MSek. Eine Garantie, dass das dann genau zu dem Zeitpunkt aufgerufen wird, wann es soll, kann ich nicht geben. Speziell wenn das System ausgelastet ist! Aber bei einem Timer ist das noch weniger der Fall.

Allerdings frage ich mich, warum du einen Thread mit einem Interval brauchst, der sowieso nur einmal aufgerufen wird? Wenn du das unbedingt in einen Thread packen willst solltest vielleicht sagen 1 Thread zum anzeigen der OSD. Der läuft permanent und wartet auf eingaben (Text was er anzeigen soll). Wenn Text da ist, dann anzeigen und warten. Wenn in der Zwischenzeit anderetext kommt, dann den anzeigen und wieder warten. Wie du das genau machst stand auch in dem Tut. Siehe TEvent. damit kann man so etwas ziemlich einfach realisieren.

Tach,

leider muss ich sagen ich hab das ganze in ähnlicher form gemacht und es funzte nicht mehr richtig für die SkinEngine. Bilder die gezeichnet werden haben angefangen zu flimmern ich bin halber verzweifelt, bin jede zeile code der skinengine durch gegangen und hab keinen fehler gefunden, dann es ja bei Timer gefunkt hatte, lag es also an dem Thread... also hab ich einfach mal den rotz Synchronize gemacht, was das flimmern verhinderte... was aber auch noch mist war, er hat das Execute nur einmal ausgeführt.
Irgendie war dann das Resume und Suspend komisch drauf und haben sich nach belieben einfach mal getauscht...
Ich will es aber immer wieder ausführen lassen, so lange ich meine vorher definierte variable FEnabled auf TRUE ist.

Aber meinst du ich soll einfach nur für die reset ereignisse Threads benutzen ??
Das Blöde ist aber das ich z.b. das OSD für 3 secs anzeigen will... und mein DirectX alle 20 MSecs das Vid Refreshed und hät ich das OSD nur einmal gezeichnet, würde das nach 20 MSecs gleich wieder weg sein, das wäre nicht so sehr toll

Das mit dem Sync peil ich überhaupt nicht, warum und wann ich es einsetzen muss.

matane,
Final

btw. TCriticalSection fehlt TryEnter bzw. TryAcquire = (TryEnterCriticalSection(FSection))
= das nichtblockierende Pendant zu Enter/Acquire; gibt False zurück wenn die Resource bereits gelockt

_________________
...

Also ich meine das nicht. Einen Thread so umzustricken, dass ein Timer draus wird ist eher sehr unüblich. Außer bei einem Watchdoc (Timeout beim Downloaden von Webseiten).
Ich weiß jetzt auch nicht, wie das mit dem DirectX funktioniert aber vielleicht kannst du das OSD ja dort einbinden. Nur so als Beispiel. Wenn du dort zum Beispiel ein Event hast dir sagt, sobald das Bild gezeichnet wurde (OnPaint). Dann kannst du dich da rein hängen. Und mittels eines Timestamps kannst du es dann nach 3 Sekunden auch wieder wech machen.
Das hat ganz entschiedene Vorteile. Du zeichnest genau dann wenn es erforderlich ist (Also nicht zu oft) Und du sparst dir dadurch einen Thread. Also den mehraufwand in der Entwicklung und zur Laufzeit.


Das geht nicht. Du musst in dem Execute eine schleife aufbauen und in dieser deine Arbeit verrichten.
PS: WinMain wir auch nur einmal aufgerufen.


Also noch mal langsam. Das Synchronize ruft eine Windowsbotschaft auf. Diese führt eine Prozedure auf. Und die Botschaften werden im VCL-Thread abgearbeitet. Das synchronize ist eine Möglickeit deine Anwendung zu synchronisieren. Dadurch, dass das Sync per Message funktioniert kann auch immer nur genau EIN Synchronize abgearbeitet werden. Es wird auch nur dann abgearbeitet, wenn deine Anwendung Botschaften verarbeiten kann. Sobald du in einem ButtonOnClick etwas lädst, was 10 Minuten dauert oder so, dann wird auch kein Sync abgearbeitet.
Syncronize sorgt also dafür, dass der VCL-Thread eine Procedure vom Thread aufruft. Dies aber nur wenn er selber gerade nichts zu tun hat.

Wann du es einsetzen musst kann ich dir auch nicht sagen. Das ist von Fall zu Fall unterschiedlich. Aber wenn eine Threadmethode unter diesen Gesichtspunkten aufgerufen werden muss, dann solltest du Synchronize verwenden.
Es gibt dafür kein Patentrezept das musst du leider immer wieder selber entscheiden. Was wir machen können ist dir die Technologie etwas näher zu bringen.

In meinem derzeitigen Projekt zum Beispiel habe ich keine einziges Synchronize eingebaut. Bisher habe ich genau eine Critical Section und das wird wohl auch so bleiben. Den Rest versuche ich so weit wie möglich voneinander fern zu halten. Also so zu Programmieren, dass sie sich einfach nicht in den Weg kommen können.

So, mein problem ist endlich beseitigt, ich hab ne Unit gebastelt mit der ich das machen kann was ich brauch. Im Grunde genommen ist es dann einfach nen Erweiterer TTimer...



wenn Fehler drin sind, oda so bitte melden.
Hab gemerkt so ein Thread frisst ganz schön CPU auslastung.

matane,
Final

deine Critical Section macht für mich keinen ersichtlichen sinn....

zum einen ist es der einzige Thread der auf die Critical Section zugreifen kann...
der Sinn besteht aber darin, dass sie für alle betroffen Threads zugänglich sein sollte...
zudem sollte sie auch nur dann verwendet werden, wenn etwas vor gleichzeitigen Lese/Schreibzugriffen
geschützt werden soll...



Zum Verständnis:

stell dir 6 leute zu je 3 Paaren in einem Raum vor.
Jedes Paar hat eine Kaffetasse und Jeder in einem Paar seine eigene Kaffekanne...
Aufgabe ist es, alle 3 Tassen so schnell wie möglich zu füllen und dabei nichts
zu verschütten!


-- Keine Synchronisierung:

die Leute aus Paar 1 schwappen gleichzeitig ihren Kaffee in die Tasse...
die Tasse läuft über und schon haben wir den Salat...
bei Paar 2 und Paar 3 genau das gleiche...

Aufgabe nicht erfüllt. fehlgeschlagen.


-- einfache Synchronisierung:

Da kommt einer auf die Idee, ne Ampel mit nem Handschalter zu installieren.
Solange Rot ist darf keiner schütten. Alle Menschen in dem Raum können die Ampel sehen! (also ne globale Ampel wenn man so will)

Mensch 1 nimmt den Schalter in die Hand, schaltet die Ampel auf Rot,
schüttet kontrolliert seinen Kaffe halb in die Tasse.
Schaltet auf Grün und gibt den Schalter an seinen Nachbarn weiter.

Mensch 2 macht das gleiche; schaltet rot, gießt den Kaffe ein, zurück auf Grün
und gibt den Schalter an das nächste Paar.
das wird wiederholt bis alle Tassen voll sind...

funktioniert zwar... aber Aufgabe ist es, so schnell wie möglich
alle Tassen zu füllen... und irgendwie ist es nicht schnell genug...
Irgendwas stimmt an der ganzen Sache noch nicht.


-- Differenziert synchronisieren:

Ein Anderer aus Paar 2 bemerkt, das es sich um 3 Tassen handelt und warum sollte
er warten bis Paar 1 seine Tasse gefüllt hat. Er schüttet doch garnichts in denen
ihre Tasse... Warum warten?
Er schlägt vor doch für jedes Paar eine eigene Ampel zu installieren.
Nun sind in dem Raum 3 Ampeln mit jeweils 3 Handschaltern.
Jedes Paar bekommt so einen Schalter.

Mensch 1 aus Paar 1 schaltet seinen Ampel auf rot
Mensch 1 aus Paar 2 genauso
ebenso Mensch 1 aus dem dritten Paar

diejenigen schütten ihren Tasse halb voll. Schalten alle auf Grün und
geben den Schalter an den Partner. Der macht das gleiche.

und voila alle 3 Tassen sind gefüllt, relativ zügig und ohne etwas zu
verschütten.


Nun musst du dir nur noch vorstellen das diese Ampeln deine Critical Sections,
die Menschen deine Threads und der Kaffe die Daten sind und die Tasse ist der Ort
wo die Daten landen sollen. Das "Schütten" ist das Execute des Menschen(Thread).

Die Ampeln/Critical schützen also deine Kaffetasse/geteilte Resource
und nicht die Menschen/Threads wie in deinem Fall.
Mach also Critical Sections abhängig von den geteilten Daten und mach sie vor allem den
beteiligten Threads sichtbar. Die zwei Paar-Partner in dem Beispiel haben
die Ampel sehen können und konnten sich so untereinander koordinieren...


hoffe habs n bissel deutlicher machen können...
btw, das ist ne sinngemäße und keine technische Darstellung

_________________
...

n bissel viel geworden

_________________
...