Meldung bei ParallelFor - Assistent für verwaltetes Debuggen "ContextSwitchDeadlock"

  • VB.NET

Es gibt 5 Antworten in diesem Thema. Der letzte Beitrag () ist von Coldfire.

    Meldung bei ParallelFor - Assistent für verwaltetes Debuggen "ContextSwitchDeadlock"

    Ich habe mit ParallelFor experimentiert. Diesmal scheint es fast zu klappen. Nur stört diese Meldung.

    Assistent für verwaltetes Debuggen "ContextSwitchDeadlock"
    Die CLR konnte 60 Sekunden lang keinen Übergang vom COM-Kontext 0xb5d92550 zum COM-Kontext 0xb5d92428 durchführen. Der Thread, der Besitzer des Zielkontexts/-apartments ist, wartet entweder, ohne Meldungen zu verschieben, oder verarbeitet eine äußerst lang dauernde Operation, ohne Windows-Meldungen zu verschieben. Eine solche Situation beeinträchtigt in der Regel die Leistung und kann sogar dazu führen, dass die Anwendung nicht mehr reagiert oder die Speicherauslastung immer weiter zunimmt. Zur Vermeidung dieses Problems sollten alle STA-Threads (Singlethread-Apartment) primitive Typen verwenden, die beim Warten Meldungen verschieben (z. B. CoWaitForMultipleHandles), und bei lange dauernden Operationen generell Meldungen verschieben.

    Danach gegoogelt und folgendes gefunden: mycsharp.de/forum/threads/5116…lock-erkennen-und-umgehen

    Zitat "Einfach die Exception in den VS-Einstellungen abschalten und gut ist."

    Ich habe in den Einstellungen gesucht, aber nix gefunden. Wie kann ich diese Meldung beim Debuggen wegbekommen?
    Aktuelles Projekt: Z80 Disassembler für Schneider/Amstrad CPC :love:

    Ich glaube nicht, dass es sinnvoll ist, diese Meldung deaktivieren zu wollen. Ist es richtig, dass Dein Programm ne Minute nicht ansprechbar ist, also (falls vorhanden), das GUI nicht reagiert? Falls ja: könnte die Parallel-For-Geschichte nicht nebenläufig vor sich hin werkeln?
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Ich habe die Einstellung gefunden.



    Ich habe das Programm nochmal gestartet. Bisher läuft es durch. Deine Frage verstehe ich nicht.

    Hier mein Code:

    VB.NET-Quellcode

    1. Dim Timer1 As Date
    2. Dim Timer2 As Date
    4. Timer1 = Date.Now
    5. Schleifen2(0, 2513169434917)
    6. Timer2 = Date.Now
    7. Debug.WriteLine(Ticks2Zeit(Timer2.Ticks - Timer1.Ticks))
    8. End Sub
    10. Sub Schleifen2(Von As Long, Bis As Long)
    11. Dim Ergebnis As Long
    12. Dim result = Parallel.[For](Von, Bis, Sub(i1, state)
    13. Ergebnis = TuWas(i1, Bis)
    15. If Ergebnis = -1 Then
    16. state.Stop()
    17. End If
    18. End Sub)
    19. End Sub
    21. Public Function TuWas(Counter As Long, Bis As Long) As Long
    22. If Counter = Bis - 1000 Then
    23. Return -1
    24. End If
    25. Return Counter
    26. End Function
    Aktuelles Projekt: Z80 Disassembler für Schneider/Amstrad CPC :love:

    Dein Programm hängt eine Minute fest. Der User könnte also denken, dass es bis in alle Ewigkeit festhängt. Was Dein Programm macht, versteh ich weder, noch ist es relevant. Was ich wissen wollte: Ist es Absicht, dass Dein Programm während der Ausführung nicht benutzbar sein soll?
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Neu

    Also ich habe auch häufiger mit dieser Meldung zu tun. In verschiedenen Kontexten. Mal ist es eine SQL-Abfrage, mal eine Implementierung, die sehr unpofessionell mit dem Speicher umgeht ( und Aufwand/Nutzen das zu fixen sind zu hoch, als das ich dafür grünes Licht bekommen könnte). Das generelle deaktivieren gefällt mir aber nun auch wieder nicht. Leider verstehe ich die Empfehlung nicht :Zur Vermeidung dieses Problems sollten alle STA-Threads (Singlethread-Apartment) primitive Typen verwenden, die beim Warten Meldungen verschieben (z. B. CoWaitForMultipleHandles), und bei lange
    dauernden Operationen generell Meldungen verschieben.