ironhaert - Mi 05.05.10 16:40
Titel: Threading - Threadanzahlmaxium für ein OS - eure Erfahrungen

---

Hallo,

Generell hätte ich noch ein paar Fragen die sich zu diesem Thema aufgetan haben:
Die Sache ist die, da in der Perfomance der Prozoessorenwicklung durch Taktzyklus die technische Hürden gerade groß sind und daher immer mehr höhre Multicores gibt. Dazu kommt noch, dass Anwendungen heutzutage als verteilte Systeme stattfinden und sich Threads somit über normale Systemgrenzen hinausbewegen.

Die MSDN-Lib sagt allgemein nur wegen Gründen des Speicherhandligs, nur ganz Allgemein, so wenig wie möglich Threads bezutzen.
Wie sieht is mit der Grenze einer Threadanzahl in einem OS aus bzw. diese ist ja vom Speicher, wenn ich mich net irre, begrenzt?
Was ist eurer Meinung nach eine "sinnvolle" und was eine maximal Anzahl an (aktiven/wartendenden) Threads auf einem OS; =CoreAnzahl, x>CoreAnzahl oder was ganzAnderes?
Also VS gab mir ne Exception beim Bouncer-Bsp (is glaub von der MSDN-Lib) für semaphoren nach ca. 1500. (Klar, das sind jezz wirklich en bisschen viele, aber he, wer weiß wo di Zukunft hinführen wird?) Wobei dies ne OutOfMemoryException war und der Speicher sicherlich hierfür sicherlich irgendwo einstellbar ist.
Welchen Ressourcenverbrauch bringt ein schlafender Thread mit sich, außer Speicherbelastung des OS?

Hm...demnächst mal auf VS 2010 umsteigen und mal wirklich schauen was .NET 4.0 da mit sich bringt.

Grüße.
ironhaert

Gausi - Mi 05.05.10 17:00

---

Das kommt immer darauf an, was du machen willst. Wenn du eine hochgradig parallelisierbare Aufgabe lösen willst, und 1000 Kerne zur Verfügung hast, kannst du 1000 Threads nutzen. Wenn du eine komplexe Aufgabe zu lösen hast, die sich nicht (einfach) in mehrere Teilaufgaben zerlegen lässt, die in ihrem Speicherbereich für sich werkeln, dann nützen dir die 1000 Threads ungefähr gar nichts, da diese dann fast nur damit beschäftigt sind, ihre Lese- und Schreibzugriffe gegenseitig abzustimmen anstatt wirklich zu arbeiten. Eigentlich braucht man dann sogar länger.

Für eine normale Anwendung sollten es imho nicht mehr als ein halbes Dutzend sein. Einer für die GUI, und dann ein paar, die ggf. im Hintergrund arbeiten, z.B. Dateien scannen, Zeug aus dem Netz runterladen, Grafik-Rendering, ...

OutOfMemory-Exception kann im Zusammenhang mit Threads auch andere Ursachen haben. Ich bekomme diese Meldung regelmäßig, wenn ich mit Bitmaps in Threads arbeite - das ist nämlich böhse. ;-)

Kha - Mi 05.05.10 17:20

---

ironhaert hat folgendes geschrieben :

Welchen Ressourcenverbrauch bringt ein schlafender Thread mit sich, außer Speicherbelastung des OS?

Ich gehe mal stillschweigend davon aus, dass du den CLR-Threadpool benutzt: Einen Thread davon :D . Der Threadpool geht davon aus, dass die abzuarbeitenden Aufgaben relativ kurz sind und der Thread damit bald wiederverwendet werden kann. Wenn du nun einen Poolthread sperrst, muss ein neuer Thread erstellt werden. Und das ist richtig teuer (relativ gesehen ;) ) und wird vom Pool deshalb auch hinausgezögert. Gegen eine Handvoll selbst und einmalig im Programm erstellter Threads spricht aber natürlich nichts, es geht wie so oft nur um Code in engen Schleifen.

Es stellt sich doch die Frage: Wozu eine vertragbare Anzahl festlegen und nicht einfach genau so viele Threads wie nötig einsetzen? Für "Embarassingly Parallel"-Probleme Environment.ProcessorCount, fürs Warten auf I/O überhaupt keine, sondern die entsprechende Async-Methode :zwinker: , fürs Warten auf andere Threads ab sofort eher Task.ContinueWith/ContinueWhenAll/...