... the user friendly GPS tool


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Vorabversion 2.16 - Thread zum Melden von Problemen
#41
Hallo Christian,

(08.07.2016, 20:42)routeconverter Wrote: Eigentlich wird ja nur PositionReducer#clear() sowie 1 von 2 Aufrufen von PositionReducer#hasFilteredVisibleArea() mit dem notificationMutex Lock geschützt. Das sieht in der Tat nicht schlau aus.

da widerspreche ich dir nicht. Die ganze Klasse ist nur schwer in allen Facetten zu verstehen. Die ganzen Hilfsthreads, die dann doch ihren Worker-Teil per Mutex verriegeln, sind schon etwas schwer zu lesen. Ich hätte fast gesagt, dass ein Single-Thread-Scheduled-Executor das etwas übersichtlicher machen könnte (keine Threads und Mutex). Allerdings müsste man sich dann für das vorzeitige Wecken etwas neues überlegen.

Ich bin mir allerdings nach der neusten Debug-Session nicht mehr so sicher, ob es das Problem lösen würde.
Ich habe inzwischen 2 Varianten von dem Fehler hin bekommen.
1. visible ist null (war auch die Variante, die ich beim letzten Mal hatte)
2. visible ist nicht null, aber "isWithinVisibleArea" liefert true

In meiner Version mit diversen Logausgaben habe ich nun gesehen, dass es vorkommt, dass der "positionListUpdater"-Thread auslöst, aber der PositionReducer nichts gemacht hat.
Wenn ich mir nun den Code anschaue und auch etwas über meine Bedienung nachdenke, so habe ich die Vermutung, dass wir es mit 2 Fehlern zu tun haben:


1. die Neuberechnung läuft, aber der Clear-Aufruf löscht parallel die Daten (speziell das inzwischen aktualisierte "visible"). Anschliessend aktualisiert die Neuberechnung aber erst den Cache.
Das Ergebnis ist, dass wir einen Wert im Cache haben, aber kein gesetztes visible. Beim nächsten Durchlauf bekommt zwar der "positionListUpdater"-Threads einen Update der Positions, aber löst keine echte Neuberechnung aus, da der Cache doch Daten enthält. Das "visible"-Feld wird folglich nicht mehr gesetzt und alle nachfolgenden Aufrufe von "centerChange" machen nichts.

2. man ändert schnell den Zoom (zoomt hinein ?) In den Cache werden Werte für den falschen Zoomlevel geschrieben. Folglich gibt's beim anschließenden Verschieben keine Neuberechnung, da man ja noch in dem vermeintlich sichtbaren Bereich (des eigentlich anderen Zoomlevels) ist.

Schalte ich den Cache ab (kommentiere das "reducedPositions.put(zoom, result);" aus, so kann ich den Abbruch der Linie nicht mehr reproduzieren (da dadurch beide Probleme nicht mehr auftreten können).

In meinen Augen müsste man daher folgendes machen:
1. den clear- und die reducePositions-Aufrufe auf dem PositionsReducer gegeneinander verriegeln.
2. sicherstellen, dass die Werte, die beim reduzieren der Positionen aus dem Callback bestimmt werden, komplett zueinander passen (die Grenzen auch dem Zoomlevel entsprochen haben).

Gruß
Thomas
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)