lock über verteilte Objekte?

Hallo,

folgende Situation: Ich habe eine Manager-Klasse und mehrere untergeordnete Klassen, die von diesem Manager verwaltet werden. Der Zugriff auf diese untergeordneten Klassen erfolgt entweder über den Manager oder eventgesteuert.

Das Problem liegt nun in der Threadsicherheit - denn wenn der Manager zwei Methoden an der untergeordneten Klasse aufruft, so können diese für sich genommen zwar threadsafe gestaltet werden (halt ein lock auf ein Lockobjekt), nur ist das ganze nicht unbedingt threadsafe, denn:

• Manager ruft Methode A auf
• Per Event wird Methode C ausgelöst
• Manager ruft Methode B auf

Durch C ändert sich aber der Status, so dass die Informationen für B nicht mehr stimmen ...

Wie kann ich dieses Problem lösen? Ich weiß nicht so recht, in welche Richtung ich denken soll - wie kann man an so etwas herangehen?

Viele Grüße,

Golo

Hallo,

Original von Golo Haas
Durch C ändert sich aber der Status, so dass die Informationen für B nicht mehr stimmen ...

Ich glaube die Informationen reichen nicht ganz um Dir da weiterzuhelfen.
Wie soll denn das ganze aussehen? Hätte B schon unbedingt vor C laufen müssen, oder darf B nicht mehr laufen weil sich der Status geändert hat? Hängt der Aufruf von B irgendwie vom Aufruf von A ab?
Ich denke das Problem wird wahrscheinlich darauf hinauslaufen, daß du eine Klasse brauchst, die die Events UND die übrige Steuerung übernimmt, um selbst zu entscheiden, wer wann an der Reihe ist.
Könntest Du vielleicht die Events ebenfalls mit dem Manager verwalten und zum richtigen Zeitpunkt an die Unterklassen schicken?

Du hast von verteilten Objekten gesprochen, also nehme ich an, dass diese Objekte irgendwo gehostet werden (Remoting, IIS, WCF). Ausgehend von Remoting müssten diese Objekte Singleton- oder Client-aktiviert sein (Sonst könnten sie keinen Status halten). Bei Singleton trifft jeder Clientaufruf in einem eigenen Thread ein. In welcher Weise hast Du genau Probleme/Bedenken mit der Threadsicherheit?

Kommt der Status bei "gleichzeitig" aufrufenden Clients durcheinander?
Machst Du in der Manager-Klasse eigene zusätzliche Threads auf?

Einfach mal frei heraus: Wenn ich sicherstellen wollte, dass der Code aus Methode A und B nacheinander ausgeführt wird, ohne dass C dazwischenfunkt, dann würde ich daraus entweder eine Methode machen oder die entscheidenden Objekte in A sperren und erst in B wieder freigeben.

Frage: C ist doch ein Event, der andere Objekte benachrichtigt. Warum findet erst dort der Zustandswechsel statt? Verletzt m.E. das Prinzip der Kapselung.

Ansonsten würde dem zustimmen, was Lord Hessia schrieb. Wenn Der Aufruf einer Methode inkl. anschließendem Event singlethreaded sein muss, dann muss du das Objekt eben so lange sperren. Um die Sperrzeiten zu minimieren könntest du die Methoden in schreibende und nur lesende aufteilen und über ReaderWriterLock sperren. So können mehrere Threads parallel auf dem Objekt lesen, aber nur ein kann schreiben bei Ausschluss von Lesern.

@LordHessia
Das klappt aber nur dann, wenn der Aufruf von B auch sichergestellt ist. Vielleicht steht ja beim Aufruf von A überhaupt noch nicht fest daß B überhaupt läuft, und dann würde A das Objekt für die Ewigkeit blockieren 🙁
Die Informationen sind einfach etwas dürftig, was überhaupt passieren soll.

Original von Lord Hessia
Einfach mal frei heraus: Wenn ich sicherstellen wollte, dass der Code aus Methode A und B nacheinander ausgeführt wird, ohne dass C dazwischenfunkt, dann würde ich daraus entweder eine Methode machen oder die entscheidenden Objekte in A sperren und erst in B wieder freigeben.

Insgesamt war die Frage ein wenig schwammig formuliert, so wie Lord Hessia es verstanden hat, das kommt dem ganzen am nächsten.

Eine Methode lässt sich aus semantischen Gründen schlecht daraus machen, wie würde man eine solche Sperre implementieren? Hast Du ein paar Stichworte für mich?