Thread Sicherheit im komplexen Datenmodell

[nocxsville]

Hallo,

Ich habe ein (mehr oder weniger) komplexes Datenmodell im Speicher.
Das Datenmodell ist hierarchisch und umfasst zwischen 150.000 - 300.000 Objekte.
Auf das Datenmodell sollen diverse Module (ca. 7-10) aus verschiedenen Threads zugreifen.
Einige Module ändern in regelmäßigen Abständen (alle 250 ms - 1000 ms) Daten aus dem Modul. Andere ändern nur bei Bedarf und wesentlich seltener. Wieder andere greifen nur lesend zu. Die Datenänderungen sind im allgemeinen wenig zeit intensiv.

Meine Frage: Wie synchronisiere ich ein solches Datenmodell?

Ich habe bisher folgende Ideen:
(1) Über Locks in den einzelnen Typen.
Vorteil: Es werden nur die Daten gelockt, die geändert werden.
Nachteil: Das führt bei der Anzahl von Objekten zu sehr vielen Locks.

(2) Über eine zentrale Schnittstelle, über die alle Module zugreifen. Diese Schnittstelle hätte dann einen zentralen Lock.
Nachteil: Es wird immer alles gelockt, egal was geändert wird.
Vorteil: Nur ein Lock --> wenig Synchronisation-Aufwand.

(2a) Dispatch Thread (ähnlich wie in AWT/Swing):
Ein Thread der nacheinander Aufgaben (Event-Threads) abarbeitet.
Nachteil / Vorteil ähnlich wie (2) + Es werden viele Threads (Events) erzeugt.

Mich würden eure Erfahrungen interessieren.
Welche Lösung bevorzugt ihr (vielleicht eine ganz andere, die ich noch gar nicht bedacht habe)?

Vielen Dank im Voraus

 

[diggaa1984]

Ist das teilweise auch synchron oder geht auch ausschliesslich asynchron?

Du könntest ja sagen wir mal 10 Threads haben, welche in einer Queue Anfragen zu Änderungen oder Lesezugriff annehmen. Jeder Thread arbeitet dann die Anfrage ab und sperrt das entsprechende Objekt. Würde wohl deinem vorschlag von 1 gleichkommen, aber bei der Anzahl an Threads sind die Locks ja beschränkt. Nachdem der Thread fertig ist gibt er das Dokument wieder frei.

Sollte ein Thread auf ein blockiertes Element stossen, kann er entweder warten, oder macht mit der nächsten Anfrage weiter. Das nicht bearbeitete Element bleibt in der Queue (entweder wieder hinten anstellen oder sofort erneut probieren).

Die Frage ist, ob die 10 Threads asynchron laufen dürfen, oder ob Änderungen auch synchroner Natur sein können/müssen. Aber auch da könnte man eventuell durch Anpassung des Models optimieren.

 

[nocxsville]

Die Module arbeiten komplett asynchron.
Die Variante 1 hat zudem den Nachteil, dass sehr viele Typen mit Locks ausgestattet werden müssen, was die Sache sehr komplex macht und wiederum zu Fehlern/Deadlocks führen kann.

Ich habe mir mal den Beitrag von "Graham Hamilton" zum Thema Multi-Threading in GUI-toolkits durchgelesen. Hier der Link: https://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html

Natürlich sind GUI-Toolkits weitaus umfangreicher, den Kern trifft es aber ganz gut.

 

[diggaa1984]

Was meinst du mit sehr viele Typen mit locks ausstatten. Ist die Klassenhierarchie derart vielseitig und nicht in einem oder mehreren super-Objekten lockbar?
Du lockst ja nur soviel Objekte gleichzeitig wie du Threads zur Verarbeitung benötigst.

Aber die Frage ist, was genau meinst du in der Aussage mit Typen?

 

[nocxsville]

Die Komplexität der Klassenhierarchie hält sich in Grenzen. Das Datenmodell besteht aber aus einer großen Anzahl verschiedener Typen.

Aus der Luft gegriffenes Beispiel für die Veranschaulichung:

Data Model <>--- Kunde <>---Bestellung <>---Status
                                       <>---Posten <>--- Katalog Item
                       <>---Notizen
           <>--- Typ A <>--- Typ B <>--- Bestellung
...

Fallbeispiele:
- Ein Modul fügt einen Posten zu einer Bestellung hinzu. In dem Fall müsste man die Bestellung locken.
- Ein Modul ändert Eigenschaften am Kunden (zum Beispiel den Namen). In dem Fall müsste man den Kunden locken.

Für die beiden Anwendungsfälle müsste man schon die Kunde- und die Bestellung-Klasse Thread-Sicher implementieren. Im Grunde lässt sich das endlos weiterführen. Auch wenn ich die Lösung mit den 10 Threads verwende, müsste ich doch nahezu jede Klasse Thread-Sicher implementieren. Ich habe ein ungutes Gefühl, eine solch große Zahl von Thread-Sicheren Klassen zu implementieren (auch wenn am Ende nur max 10 Locks gleichzeitig aktiv sind).

Daher meine Frage, wie andere dieses Problem gelöst haben. Favorit ist immer noch Lösung (2), wenn sie auch den Nachteil hat, dass das komplette Datenmodell bei jeder Änderung gelockt wird.

 

[diggaa1984]

Wenn du beim Vorschlag 2 das KOMPLETTE Datenmodell lockst, wo kommen dann mehrere Threads in Spiel, die asynchron ändern können?

 

[nocxsville]

Mit Lösung (2) kann dann natürlich immer nur ein Thread gleichzeitig Änderungen vornehmen. Das hatte ich ja auch als Nachteil genannt.
Ja sage ja nur: "Die Module arbeiten komplett asynchron."
Das heißt nicht, dass sie auch asynchron Änderungen vornehmen. Mit Lösung (2) müssen die anderen warten.

 

[diggaa1984]

Also wenn es Threadsicher sein muss, weil asynchron schreibend darauf zugegriffen werden muss, dann muss man wohl in den sauren Apfel beissen. Ob das Auslesen auch derart wichtig ist, dass man es blockt wenn eine Änderung läuft ist auch eine Frage die man beantworten sollte.

Kommt natürlich auf die Anwendungsfälle an.
Klassisches Beispiel ist ja immer: Synchronisierte Kontenführung (Einzahlen, Auszahlen)