Buch zu den .NET-Internas?

Hallo,

C# 8.0 in a Nutshell: The Definitive Reference
978-1492051138

glandorf

"Pro .NET Memory Management: For Better Code, Performance, and Scalability" von Konrad Kokosa


Ist notiert - danke.
Dann ist das Thema bzw. sind die Themen wohl größer als gedacht - aber davon war auszugehen.

Gibt's denn noch andere Bücher, die Du empfehlen kannst, oder kennst Du eine Übersicht solcher Bücher, die man gelesen haben muss, wenn man sich für sowas interessiert?
Das Buch "C# 8.0 in a Nutshell: The Definitive Reference" klingt mehr wie eine Sprach- und Framework-Referenz und scheint keinen tiefgehenden Einblick zu bieten - also nicht das, was ich suche.

Und wenn es (hier) noch keine Übersicht für sowas gibt, dann kann das doch eine solche Übersicht werden.

Hallo Palladin007,

Zitat:

die verschiedenen Möglichkeiten, die Arbeit in mehreren Threads untereinander zu synchronisieren

Auch wenns alt ist, ist es immer noch korrekt und ein "Klassiker":  http://www.albahari.com/threading/
An den grundlegenden Dingen wird sich hier auch in Zukunft nichts ändern, da die Konzepte für CPUs und Speichermodelle sich "hier nicht weiterentwickeln". Das wäre ggf. mächtige Brüche mit der Kompatibilität.

 http://joeduffyblog.com/ (v.a. die alten Beiträge) sind hier ebenfalls eine gute Quelle, die teils sehr in die Tiefe gehen -- nicht zuletzt wegen Joe Duffys damaligen Job für das entsprechende .NET Team.

mfG Gü

Hallo Palladin007,

also ich kann  http://www.albahari.com/threading/ auch nur sehr empfehlen. Ich glaube nicht, dass es was besseres als Buch gibt bzw. das ist ja eigentlich ein Buch/PDF.

Wobei ich so konkret an Code bzw. Konstrukten orientierte Themen eh nicht ohne PC lesen kann, da ich das Gelesene immer sofort in konkrete Beispielprogramme umsetzten und ausprobieren muss. Allerdings hilft Testen im klassischen Sinne bei Nebenläufigkeit nur sehr begrenzt. Da muss man dann besser einen bösartigen Scheduler spielen. Und das erfordert - zumindest bei mir - höchste Konzentration. Das kann ich eh nur am Schreibtisch - und da steht dann sowieso der PC. Womit sich der Kreis schließt.

Zum bösen Scheduler habe ich in  SyncQueue <T> - Eine praktische Job-Queue einen - wie ich finde sehr lehrreichen - Fall angegeben, wo man den Fehler durch Testen wohl kaum gefunden hätte und in  SyncQueue<T> erweitern: Enqueue blockiert bei voller Queue (in: "Das Programmier-Spiel") folgende Erläuterung geschrieben, wie man vorgehen kann/sollte, um solche Fälle aufzudecken:

Zitat:

[...] weil der Reiz dieser Aufgabe in meinen Augen in gerade im Knobeln und im Kniffligen liegt. Man muss das Ganze wirklich tief durchdenken. Man muss, wie in dem o.g. Link exemplarisch beschrieben, versuchen, einen möglichst bösartigen Benutzer und zusätzlich einen möglichst fiesen Scheduler zu spielen. Der Benutzer führt die Aufrufe in möglichst böser Reihenfolge in einer vertrackten Umgebung von Threads aus und der Scheduler zerhackt das Ganze noch in möglichst ungünstige Häppchen und wechselt zum jeweils unpassendsten Thread. Und dann muss immer noch alles stimmen. Den bösen Benutzer kann man natürlich auch in Form von gemeinen Testprogrammen "spielen". Aber den bösen Scheduler kann man bei einem Test, bei dem man das Programm einfach laufen lässt, gar nicht oder nur sehr, sehr schwer simulieren. Das geht weit besser im Kopf. [...] Wer selbst fiesen Scheduler spielen möchte, kann das - für mehrere andere Synchronisierungsaufgaben - auf der extrem coolen Seite  The Deadlock Empire - Slay dragons, master concurrency! tun. Per Knopfdruck kann man dort bestimmen, welcher Thread die jeweils nächste Anweisung ausführen soll und man sieht quasi wie im Debugger sofort, wie sich daraufhin der Programmzustand ändert. Dabei ist es (Spiel-)Ziel, die (jeweils nicht korrekt implementierte) Synchronisierung auszutricksen oder das Programm in einen Ausnahmezustand zu versetzen.

In diesem Zitat "versteckt" sich der Link auf eine weitere Quelle, die ich - neben der Prosa - hier noch beisteuern wollte.

herbivore

PS: Damit man nicht jeden Anwendungscode so intensiv auf Probleme mit der Nebenläufigkeit untersuchen zu müssen, bietet es sich an, im Anwendungscode nicht selbst die Konstrukte (Semaphoren, Kritische Abschnitte, ...) der Nebenläufigkeit zu verwenden, sondern eben solche Klassen wie die SyncQueue, die einem die Details der Synchronisation abnehmen und bei denen man sehr wenig beachten muss (im Grunde genommen nur, dass der einstellende Thread nur bis zum Einstellen auf die gemeinsamen Daten zugreift und der herausholende erst ab/nach dem Herausholen.