Thread verursacht wachsenden Speichergebraucht

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    Thread verursacht wachsenden Speichergebraucht

    Moin,

    ich habe mir einen Simplen Thread gebastelt, der ein Gridview löschen, refreshen oder resizen soll. Der läuft in einer Dauerschleife und verursacht bei mir anscheinend ein erhöhten Speicherbedarf bis die Anwendung aussteigt.

    Ich bin noch ein wenig Greenhorn wenn es um Threading geht, daher meine frage, was mache ich falsch?


    Das ist mein Thread:

    VB.NET-Quellcode

    1. Private Delegate Sub ResizeColumnsDelegate()
    2. Private Delegate Sub ClearAlarmboxDelegate()
    3. Private Delegate Sub AlarmboxRefreshDelegate()
    5. Private Delegate Sub WriteAlarmboxDelegate(Datetime As String, Group As String, Text As String)
    7. Private Sub Alarmdatenlesen()
    8. Dim DeliResize As New ResizeColumnsDelegate(AddressOf ResizeColumns)
    9. Dim DeliWrite As New WriteAlarmboxDelegate(AddressOf WriteAlarmbox)
    10. Dim DeliClear As New ClearAlarmboxDelegate(AddressOf ClearAlarmbox)
    11. Dim DeliRefresch As New AlarmboxRefreshDelegate(AddressOf AlarmboxRefresh)
    13. SyncLock Me
    15. While True
    17. If (Me.InvokeRequired) Then
    18. Me.Invoke(DeliResize)
    19. Else
    20. Me.ResizeColumns()
    21. End If
    23. If Not Main._SendRecieve.Connectionstate Then
    25. If (Me.InvokeRequired) Then
    26. Me.Invoke(DeliResize)
    27. Me.Invoke(DeliClear)
    28. Me.Invoke(DeliWrite, Date.Now.ToString, "PLC", "No Connetion")
    30. Else
    31. Me.ResizeColumns()
    32. Me.ClearAlarmbox()
    33. Me.WriteAlarmbox(Date.Now.ToString, "PLC", "No Connetion")
    34. End If
    36. End If
    37. If (Me.InvokeRequired) Then
    38. Me.Invoke(DeliRefresch)
    39. Else
    40. Me.AlarmboxRefresh()
    41. End If
    43. Thread.Sleep(500)
    44. End While
    45. End SyncLock
    46. End Sub


    Und so starte ich den Thread:

    VB.NET-Quellcode

    1. Private AlarmThread As New Thread(New ThreadStart(Sub() Alarmdatenlesen()))
    3. Sub New() 'ByRef Alarmtable As Alarmboxdatatable)
    4. 'Nicht zur Designzeit ausfuehren:
    5. If System.ComponentModel.LicenseManager.UsageMode = System.ComponentModel.LicenseUsageMode.Designtime Then Return
    7. ' Dieser Aufruf ist für den Designer erforderlich.
    8. InitializeComponent()
    10. 'Werte aus der Einstellung uebernehmen
    11. Me.Columns.Clear()
    12. DataGridSettings()
    14. 'Lese -und Schreibethread starten
    15. AlarmThread.IsBackground = True
    16. AlarmThread.Start()
    18. 'Me.DataSource = Alarmtable
    19. Me.DoubleBuffered = True
    21. RemoveHandler MyBase.Resize, AddressOf Alarmbox_Resize
    22. AddHandler MyBase.Resize, AddressOf Alarmbox_Resize
    24. End Sub


    Wäre über Tips echt dankbar


    @Rizzle Wahrscheinlich genügt es, das ganze Thread-Gedöns raus zu nehmen.
    Pack mal in die Zeilen nach dem Else von If (Me.InvokeRequired) Then einen Haltepunkt und überzeuge Dich davon, dass innerhalb einer Thread-Prozedur Me.InvokeRequired stets True ist.
    Was geschieht in den Prozeduren ResizeColumns, WriteAlarmbox, ClearAlarmbox, AlarmboxRefresh?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Moin,

    da mache ich nichts besonderes schreibe in eine Datatable, Refresh das Control und lösche eine Datatable
    Wenn ich die auskommente Datatablesachen auskommentiere, steigt der Speicher immernoch an...

    VB.NET-Quellcode

    1. Private Sub WriteAlarmbox(Datetime As String, Group As String, Text As String)
    2. If Me.Columns.Count > 2 Then
    3. Main._SendRecieve.AlarmTable.Rows.Add(Datetime, Group, Text)
    4. End If
    5. End Sub
    7. Private Sub ClearAlarmbox()
    8. Try
    9. Main._SendRecieve.AlarmTable.Rows.Clear()
    10. Catch ex As Exception
    11. Log.Error(ex)
    12. ShowError(ex)
    13. End Try
    14. End Sub
    16. Private Sub AlarmboxRefresh()
    17. Try
    18. Me.Refresh()
    19. Catch ex As Exception
    20. Log.Error(ex)
    21. ShowError(ex)
    22. End Try
    23. End Sub

    @Rizzle Ist dieser permanente Aufruf erforderlich?
    Schmeiß mal das Thread-Gedöns raus, Du musst sowieso permanent invoken, und mach das in eine Timer-Tick-Prozedur.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Ich hatte das vorher in einem Timer, dann frisst der den Speicher nicht. Dann ruckelt aber die Anwendung =/

    Der Städnige aufruf ist nötig weil die Datasource sich selbst ja leider nicht aktualisiert.

    Ich verstehe aber auch einfach nicht, wieso das Speicher frisst?

    Rizzle schrieb:

    Ich hatte das vorher in einem Timer, dann frisst der den Speicher nicht.
    Welches Intervall hatte denn der Timer?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Rizzle schrieb:

    Der hat 1000 Milisekunden bekommen.
    Das Problem könnte sein, dass der nächste Tick schon da ist, bevor der aktuelle abgearbeitet ist.
    Halte in der Timer-Tick-Prozedur als erstes den Timer an und starte ihn als letztes wieder.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

Facebook
Telefonspende