Wie löse ich das Problem ??

[Helmut Schumacher]

<pre>Hallo,
ich habe folgendes Problem.
Kurze Beschreibung der Anwendung: Es gibt drei
Jobs, jeder Job startet 145 Threads. Die Jobs
kommen zu unterschiedlichen Zeiten. Der erste
alle vier Stunden, der zweite jede Stunde und
der dritte alle 15 Min.
Damit die Anzahl der gleichzeitigen Threads
begrenzt ist, gibt es eine Semaphore.
Das funktioniert so einwandfrei.
Wenn aber nun zufällig mehrere Jobs kommen,
z. B. der erste ist mitten drin, dann kommt
der Job zwei da zu. Das Semaphre Objekt
begrenzt nun immer noch die maximale Anzahl
und in der "Schlange" stehen nun die Threads
des "Vierstundenjobs". Nur soll der Job, der alle
15 Min kommt, mit höherer Prio laufen, so das das
Semaphre Objekt diese Threads vor läst.
Ist das möglich ??

Helmut </pre>

[Andreas Kosch]

Hallo,

abgesehen davon, dass es keinen Sinn macht, mehr als 10 Arbeits-Threads je CPU (die nicht nur warten) parallel laufen zu lassen, könnte man die Thread-Prioriät der "wichtigeren Jobs" erhöhen. Die Begrenzung der Thread-Anzahl muss dann je Job-Typ erfolgen

[Helmut Schumacher]

<pre>Hallo,
der Rechner hat vier Prozessoren und
ist daher schon recht schnell.
Wenn ich das richtig verstanden habe,
komme ich mit einer Semaphore nicht hin?
Also ich brache für jede Gruppe eine.
Windows ist also nicht so schlau, daß die
Thread mit höherer Prio vorgelassen werden,
wenn ich nur eine benutze.
----------------------------------
Nun habe ich die Prio mal unterschiedlich
eingestellt.
Dann stelle mehr ein zufälliges durchlassen,
wenn ich es mal so ausdrücken kann, fest.
Die Threadgruppe die als letzte an der
Semaphore ankommt, ist nicht auch gleich
die letzte die drüber kommt. Es ist, wie gesagt irgend wie zufällig ??

Helmut</pre&gt

[Helmut Schumacher]

<pre>Hallo,
der Rechner hat vier Prozessoren und
ist daher schon recht schnell.
Wenn ich das richtig verstanden habe,
komme ich mit einer Semaphore nicht hin?
Also ich brache für jede Gruppe eine.
Windows ist also nicht so schlau, daß die
Thread mit höherer Prio vorgelassen werden,
wenn ich nur eine benutze.
----------------------------------
Nun habe ich die Prio mal unterschiedlich
eingestellt.
Dann stellt sich ein zufälliges durchlassen,
ein, wenn ich es mal so ausdrücken darf.
Die Threadgruppe die als letzte an der
Semaphore ankommt, ist nicht auch gleich
die letzte die drüber kommt. Es ist, wie gesagt irgend wie zufällig ??
Helmut</pre&gt

[B. R.]

Hallo, Auch bei 4 Processoren sind 145 Th.
nicht unbedingt sinnvoll, die Frage ist ob es Echte 4 Processoren sind oder via Hyperthreading gesplittete Processoren, dann siet das ganze noch anders aus da Hyperthreading nur Software Technisch die Processoren Splittet und der Thread doch warten muß ...

Wo zu soll das ganze denn Gut sein ?
wo für benötigst du so viele Threads ?
vieleicht kann man das anders Lösen ...

Gruß Björ

[Helmut Schumacher]

<pre>Hi,
kurz zur Anwendung. Es gibt 145 Datenbanken,
aus denen Daten in ein Datawarehous zusammen-
gezogen werden. Zu jeder Datenbank gibt
es vier Datenquader.
Der erste Quader soll von jedem
System vier mal pro Stunde gezogen werden.
Der Zweite und Dritte je einmal pro Stunde und
der vierte je 1,5 Stunden. Jeder Datenquader
wird in einem eigenen Thread abgezogen.
Nun ist die maximale sinnvolle Threadanzahl,
so wie ich ausgetestet habe bei, 20 Stück
gleichzeitig.
Um das zu erreichen gibt es ein Semaphore,
welches auf 20 eingestellt ist.
Im Verlauf kommte es vor, daß unterschiedliche
Datenquader gleichzeitig, so zu sagen dran
sind. Mir ist jetzt nicht klar wie Windows
die Reihefolge, der Threads regelt, die vom
Semaphore-Objekt durch gelassen werden. Es
soll eine Ordnung rein. Windows regelt das
irgend wie, ich sehe aber kein System darin.

Helmut </pre&gt

[B. R.]

Hi,

nun ja, du hast halt die möglichkeit über die
Thread Prio. das wäre eine Möglichkeit es zu Steuern da ja der Niedrigste zum schluß dran kommt und der mit der Hösten halt zu erst.
Ich weiß ja nicht welches Packet nun eher drann kommen soll aber ich denke wenn du erkenst welches Packet du gerade bearbeitest solte das kein Prop. sein .

Gruß Björn

Ne wirklich sinnvolle Idee ist mir bis heute noch net eingefallen dazu ..