Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Async Task-Synchronisation
Palladin007
myCSharp.de - Member

Avatar #avatar-4140.png


Dabei seit:
Beiträge: 1.782
Herkunft: Düsseldorf

Themenstarter:

beantworten | zitieren | melden

Naja, meine eigentliche Grundidee (und auch der Anwendungsfall, aus dem sie entstanden ist) sieht so aus, dass es mehrere Klassen gibt, die auf eine Ressource zugreifen.
Das Lock existiert also klassenübergreifend, z.B. statisch oder in einem Singleton.
Die einzelnen arbeitenden Klassen haben dann ihr Ticket jeweils pro Instanz und können somit erzwingen, dass nur diese eine Instanz etwas tun darf, bis sie selber fertig sind.

Nun kann es aber sein, dass die arbeitende Instanz aus irgendeinem Grund (das wäre definitiv ein Bug) nicht mehr existiert, das Lock vorher aber nicht korrekt freigegeben wurde.
In diesem Fall würde das Lock dann auf ewig gesperrt bleiben, weil niemand mehr eine Referenz auf das Ticket hat - also ein Deadlock.
Durch die WeakReference würde dieser Deadlock irgendwann (indirekt durch den GC) wieder freigegeben werden.
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 6.829
Herkunft: Waidring

beantworten | zitieren | melden

Hallo Palladin007,
Zitat
Nun kann es aber sein, dass die arbeitende Instanz aus irgendeinem Grund ... nicht mehr existiert, das Lock vorher aber nicht korrekt freigegeben wurde.
Dazu ist der Releaser ja mit using (bzw. try-finally-Dispose) versehen. Somit wird auch im Fehlerfall der Lock korrekt verlassen.
Zitat
Durch die WeakReference würde dieser Deadlock irgendwann (indirekt durch den GC) wieder freigegeben werden.
Wahrscheinlicher ist aber, dass dadurch jemand Zugriff zum Lock hat der nicht sollte -- siehe oben.
Statt der WeakReference, die eben nicht deterministisch ist, wäre eine Art Deadlock-Detection möglich. Schauen wie viele beim Warten vor dem Lock sind und wie viele im Lock sind. Wenn da nichts passiert (eine bestimmte Zeit) so mag das als Indiz für den Deadlock verwendet werden, der dann entsperrt wird.

Od. weniger kompliziert: eine automatische Entsperrung nach einer bestimmten Zeit. Wenn z.B. die Arbeiten im geschützen Gebiet X Sekunden dauern, so wird das Ticket automatisch noch 2X entfernt. Wird der Lock verlassen, so den Timer zurücksetzen, etc.

Dann ist das Verhalten wenigsten deterministisch und keine Bug-Quelle.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
private Nachricht | Beiträge des Benutzers