Wie viele Threads kann man in einer Anwendung starten?

[Thomas83]

hi,

wie viele Threads kann ich in einer Anwendung starten?
So das Windows und meine Anwendung das noch hinbekommt.

Gibt es da eine Begrenzung?

[o0o]

bin mir nicht sicher aber ich denke es gibt keine begrenzung...^^

ok mit ueber 20threads hab ich auch noch nicht gearbeited aber was hast du vor bzw wieviele threads willst du denn?^^

o0o

[RavenIV]

Zitat:

Zitat von Thomas83

wie viele Threads kann ich in einer Anwendung starten?
So das Windows und meine Anwendung das noch hinbekommt.

Ich denke schon, dass es eine EInschränkung gibt.
Spätestens, wenn keine Handles mehr verfügbar sind.

Ich meine, mich zu erinnern, dass es vor langer Zeit mal eine Diskussion darüber gab.
Such doch mal nach "Anzahl Handles" oder so.

Und schreibe Deine Erkenntnis dann auch wieder hier rein.

[sirius]

Hier steht zum Beispiel das:

Zitat:

Jeder Thread muss verwaltet werden, was eine Anwendung langsamer macht und Arbeitsspeicher benötigt. Nicht umsonst weist Borland darauf hin, dass bei einem Ein-Prozessor-System 16 aktive Threads eine praktikable Obergrenze darstellen.

[sakura]

Wenn jeder Thread rechenintensive Aufgaben übernimmt, dann ist die max. sinnvolle Anzahl die der Prozessoren bzw. Cores. Auf Prozessoren mit HT, weniger eins. Das sind meine Erfahrungen.

Wenn Deine Threads aber viel Zeit mit "Warten" verbringen, dann sind mehr durchaus praktikabel.

...:cat:...

[pitti platsch]

Also ich hatte mal aus langeweile ein Programm geschrieben, dass ständig neue Threads erstellt. Habs gestartet und nach wenigen Sekunden reagierte mein System kaum noch (Ein-Prozessor-System). Der Taskmanager war offen und zeigte mir um die 7000 Threads an. Task beenden oder PC herunterfahren ging nicht. Da half nur der Resetknopf.

Fazit:
Es gibt definitiv eine Obergrenze^^

[Thomas83]

es soll per dienst verschiedene dinge überwacht werden.
Wollte für jedes object was ich überwache einen thread erstellen.
Glaube aber das es dann zu viele werden.

[Thomas83]

oder ich erstelle für jedes objekt was überwacht werden soll einen timer, da kann ich den intervall auch noch eingeben.

[Christian Seehase]

Moin Thomas,

was für Objekte willst Du denn überwachen?
Vielleicht wäre auch WaitForMultipleObjects was für Dich

[shmia]

Ein Threadpool wäre bei sehr vielen Aufgaben gut geeignet.

Grundprinzip:
Es gibt eine Jobliste (z.B. 200 Jobs) und einen Pool von Threads (z.B. 5 Stück).
Die Threads legen los und holen sich jeweils einen Job aus der Liste und arbeiten den Job ab.
Wenn ein Thread fertig ist, dann holt er sich den nächsten unerledigten Job - bis die Jobliste leer ist.
Parallel zu den arbeitenden Threads kann die Hauptanwendung stets neue Job in die Liste eintragen.

http://www.delphipraxis.net/internal...t.php?t=111982

[Thomas83]

Zitat:

Zitat von Christian Seehase

Moin Thomas,

was für Objekte willst Du denn überwachen?
Vielleicht wäre auch WaitForMultipleObjects was für Dich

objekte ist vielleicht falsch ausgedrückt, meine mit objekte z.b verzeichnisse oder dateien.
möchte z.b 20 dateien im abstand von 10 sekunden prüfen ob eine änderung vorgenommen wurde.

[phXql]

Es gibt als Gegenstück zu den Threads noch Fiber. Diese sind leichter zu verwalten. Gibts aber erst afaik ab Win2k.

[RavenIV]

Zitat:

Zitat von Thomas83

objekte ist vielleicht falsch ausgedrückt, meine mit objekte z.b verzeichnisse oder dateien.
möchte z.b 20 dateien im abstand von 10 sekunden prüfen ob eine änderung vorgenommen wurde.

Nix einfacher als das.
Da nimmt die die Win-API die meiste Arbeit ab.
Du kannst Dich dafür registrieren, dass Du bei Änderung einer Datei/Verzeichnis benachrichtigt wirst.
Dafür gibt es auch Delphi-Komponenten.

Such mal hier im Forum oder bei torry.net nach DirectoryMonitor oder DirMonitor.

[RavenIV]

Zitat:

Zitat von phXql

Es gibt als Gegenstück zu den Threads noch Fiber. Diese sind leichter zu verwalten. Gibts aber erst afaik ab Win2k.

Hast Du dazu mehr Infos oder Beispiele.
Das kenn ich nämlich auch nicht...

[Meflin]

Zitat:

Zitat von Thomas83

oder ich erstelle für jedes objekt was überwacht werden soll einen timer, da kann ich den intervall auch noch eingeben.

Blöde Idee ;) Ein Timer ist ein Thread :stupid:

[Apollonius]

Ich glaube nicht, dass Fiber hier nützlich sind.
Für die, die nicht wissen, was Fiber sind: Ein Thread kann mehrere Fiber verwalten. Mit Fibern kann man eine Art Multithreading realisieren, aber kein präemptives, sondern nur kooperatives, da zu einem anderen Fiber nur gewechselt wird, wenn man SwitchToFiber aufruft. Da Fiber aber nicht wirklich parallel arbeiten und sich auch nicht in kurzen Zeiträumen abwechseln, denke ich nicht, dass sie in der genannten Angelegenheit von Nutzen sind.

[RavenIV]

Zitat:

Zitat von Meflin

Zitat:

Zitat von Thomas83

oder ich erstelle für jedes objekt was überwacht werden soll einen timer, da kann ich den intervall auch noch eingeben.

Blöde Idee ;) Ein Timer ist ein Thread :stupid:

Nicht ganz.
Ein Timer erzeugt einen Thread, in welchem er abgearbeitet wird.

[Luckie]

Zitat:

Zitat von RavenIV

Zitat:

Zitat von Meflin

Zitat:

Zitat von Thomas83

oder ich erstelle für jedes objekt was überwacht werden soll einen timer, da kann ich den intervall auch noch eingeben.

Blöde Idee ;) Ein Timer ist ein Thread :stupid:

Nicht ganz.
Ein Timer erzeugt einen Thread, in welchem er abgearbeitet wird.

Hä? Blödsinn. Erstellt man mit der API-Funktion SetTimer einen Timer generiert Windows in den angegebenen Intervall für das Fenster eine WM_TIMER Message, welche über die Nachrichtenschleife abgerufen und über die Fensterprozedur abgearbeitet wird. Wo ist da jetzt der Thread?

Abgesehen mal davon, gibt es entsprechende API-Funktionen, um Verzeichnisse auf Änderungen zu überwachen ([dp]Verzeichnis überwachen[/dp]).

[RavenIV]

Zitat:

Zitat von Luckie

Zitat:

Zitat von RavenIV

Zitat:

Zitat von Meflin

Zitat:

Zitat von Thomas83

oder ich erstelle für jedes objekt was überwacht werden soll einen timer, da kann ich den intervall auch noch eingeben.

Blöde Idee ;) Ein Timer ist ein Thread :stupid:

Nicht ganz.
Ein Timer erzeugt einen Thread, in welchem er abgearbeitet wird.

Hä? Blödsinn. Erstellt man mit der API-Funktion SetTimer einen Timer generiert Windows in den angegebenen Intervall für das Fenster eine WM_TIMER Message, welche über die Nachrichtenschleife abgerufen und über die Fensterprozedur abgearbeitet wird. Wo ist da jetzt der Thread?

Auch Hääähh?

Hab ich irgendwo behauptet, dass die API-Funktion SetTimer verwendet wird?
Die VCL erstellt einen neuen Thread, wenn ein TTimer verwendet wird.
Das ist doch richtig, oder nicht?

[Meflin]

@Luckie: also ich persönlich meinte ja den guten alten TTimer ;) Und ich war der Meinung dass sich der eines eigenen Threads bediente :gruebel:

[Apollonius]

Dann hast du eine andere VCL als ich. Meine verwendet SetTimer.

[sirius]

Nö, TTimer kapselt ganz billig Settimer und Killtimer.
Ich habe mich auch grad gewundert, wie ihr hier auf Threads kommt. :gruebel:

Edit: Und ich dachte schon ihr wisst mehr über die interne Funktionsweise eines Timers von Windows.

[Thomas83]

möchte aber nicht nur dateien prüfen, sondern auch anwendungen ob diese noch laufen etc.
wie würdet ihr das machen? alles mit threads? für jede anwendung /dienst einen thread oder würdet ihr nur einen thread für alles erstellen?

[Luckie]

Zitat:

Zitat von RavenIV

Hab ich irgendwo behauptet, dass die API-Funktion SetTimer verwendet wird?
Die VCL erstellt einen neuen Thread, wenn ein TTimer verwendet wird.
Das ist doch richtig, oder nicht?

Dann mach mal ein einfaches Projekt mit einem Timer und guck dir die Anzahl der Thread im Taskmanager an.

[RavenIV]

Zitat:

Zitat von Luckie

Zitat:

Zitat von RavenIV

Hab ich irgendwo behauptet, dass die API-Funktion SetTimer verwendet wird?
Die VCL erstellt einen neuen Thread, wenn ein TTimer verwendet wird.
Das ist doch richtig, oder nicht?

Dann mach mal ein einfaches Projekt mit einem Timer und guck dir die Anzahl der Thread im Taskmanager an.

Ist ja jetzt mal gut.
Ihr habt mich überzeugt.
Aber irgendwo habe ich mal gelesen, dass es so sein soll.
Überprüft hab ich das nie selbst.
Egal, es scheint nun nicht so zu sein, muss ich mir merken.

[Luckie]

Es gibt Timer die auf Threads basieren.

[RavenIV]

Zitat:

Zitat von Luckie

Es gibt Timer die auf Threads basieren.

Häähh? Wie jetzt?
Kannst Du das erläutern?
Lass mich nicht dumm sterben ;-)

[Luckie]

Alles über Timer, was man wissen muss: http://blubplayer.de/tutorials/TimerTutorial.pdf ;)

[himitsu]

Mal ganz im Ernst, ich glaub ihr sucht hier in der falschen Richtung.

ich weiß, du willst Dateien überwachen, aber schau mal nach [dp]Verzeichnis überwachen[/dp]

oder in Schnell: ReadDirectoryChangesW FindFirstChangeNotification
ReadDirectoryChangesW FindFirstChangeNotification

Zitat:

Zitat von Thomas83

objekte ist vielleicht falsch ausgedrückt, meine mit objekte z.b verzeichnisse oder dateien.
möchte z.b 20 dateien im abstand von 10 sekunden prüfen ob eine änderung vorgenommen wurde.

obrige Funktionen sagen dir, wann und "welche" Änderungen grad aufgetreten sind
und man muß nicht ständig nachsehn.

PS: für 20 Dateien würde auch ein Thread ausreichen (also nach deiner Methode)
das prüfen einer Datei sollte schließlich nichtmal 'ne Sekunde dauern.


PSS: Thread belegen Handles (und mehr) und Timer auch ... also bei Beschrenkung der Handles liegt die Grenze bei beiden gleich hoch.

[Dezipaitor]

Raymond Chen hat sich schon über die maximale Anzahl von Threads ausgelassen.

So gesehen, gibt es keine künstlich gemachte Beschränkung. Allein der Speicherplatz entscheide über die maximale Anzahl von Threads.