The Software Development Blog
Die Klasse System.Threading.Timer verfügt über eine parameterlose Dispose-Funktion zur Freigabe. Laut Dokumentation sind jedoch Timer-Ereignisse nach der Freigabe möglich. Deshalb sollte die parameterlose Variante der Dispose-Funktion besser nicht benutzt werden.
Der Einsatz von Sperren zur Thread-Synchronisation birgt immer ein Deadlock-Risiko. Blockierungen treten dann auf, wenn zwei Sperren in unterschiedlicher Reihenfolge benutzt werden. Das folgende Beispiel zeigt exemplarisch eine fehlerhafte Implementierung, die im Multithreading-Einsatz zu Deadlocks führen wird.
Die Verwendung mehrerer Abarbeitungspfade (Threads) innerhalb eines Prozesses erfordert diverse Maßnahmen zur Thread-Synchronisation, um Wettlaufsituationen auf gemeinsam genutzte Ressourcen zu unterbinden. In den meisten Fällen handelt es sich dabei um die Ressource Speicher.
Im .NET Framework sind Datentypen entweder Wertetypen oder Referenztypen. Wertetypen haben grundsätzlich einen Standardkonstruktor, der dafür sorgt, dass alle Member-Variablen mit ihrem Standardwert initialisiert werden. Als Standardwert wird dabei auf Speicherebene der Wert 0 verstanden. Es ist generell nicht möglich, für Wertetypen einen Standardkonstruktor zu implementieren.
Das .NET Framework kennt schreibgeschützte Variablen als Alternative zu Konstanten. Während der Wert von Konstanten bereits bei der Kompilierung bekannt sein muss, können schreibgeschützte Variablen zur Laufzeit im Konstruktor initialisiert werden (oder natürlich auch inline). Variablen veränderlicher Verweistypen Eine Variable kann unabhängig vom Datentyp als schreibgeschützt gekennzeichnet werden. Der Schreibschutz ist für Werttypen nach der […]
Die generelle Behandlung von Ausnahmen in Bibliotheken steigert nicht etwa die Qualität einer Bibliothek, sondern gefährdet sie eher. Diese auf den ersten Blick gewagte These kann tatsächlich auch begründet werden.
Werden mehrere Abarbeitungspfade (Threads) innerhalb eines Prozesses verwendet, sind Maßnahmen zur Thread-Synchronisation notwendig, um Wettlaufsituationen (Race Conditions) auf gemeinsam genutzte Ressourcen (meist Speicher) zu verhindern.
Erweiterungsfunktionen werden ab C# 3.0 unterstützt. Sie ermöglichen das nachträgliche Hinzufügen von Member-Funktionen zu Klassen und Schnittstellen. Versiegelte Klassen können ebenso erweitert werden, wie Klassen anderer Assemblies. Erweiterungsfunktionen können bestehende Funktionen nicht überschreiben oder verdecken. Bestehende Funktionen haben gegenüber Erweiterungsfunktionen Vorrang.