Aufgabe 6.1b

[fred]

Hi,

Frage: Verstehe ich das richtig, liegt das Problem darin, dass im Teil "on receipt of a request" im else teil "send reply... voted:=true" nicht atomar ist, und somit bei geschicktem timing P1 zweimal voted, also zunächst für P2 und dann nochmal für sich selbst?

[sander]

Hi!

Also ich hab das so verstanden: Wenn ein Prozesse (z.B. P1) nicht für sich selber stimmen bevor er den request-Multicast an alle anderen abschicken (Zeile 5), dann kann es passieren das in der Zeit die seine Votingset-Partner (z.B. P3) zum antworten braucht der request-MC von z.B. P2 bei P1 eintrifft. Da P1 nicht sofort für sich selber gevotet hat gibt er seine Stimme P2. P2 bekommt also den Zugriff. Jetzt trifft endlich die Zustimmung von P3 ein und damit hat auch P1 den Zugriff.

Wenn dir Prozesse für sich selber stimmen bevor sie einen request-MC wegschicken, dann kann das nicht mehr passieren. Allerdings ist dann ein Deadlock möglich:

Wollen z.B. alle 3 Prozesse Zugriff stimmen sie erst für sich selber, dadurch bekommt dann auch keiner von seinem Partner das OK für den Zugriff.

Stimmt doch so, oder?

[fred]

hmm oder so... macht beides sinn meiner meinung nach...
noch was zur aufgabe 7.3b. da in der lösung die 24 ms für 2x berechnen + marshalling/unmarshalling aufgeführt sind, muss der server hernach ja single threaded sein, sonst könnte er die beiden aufrufe parallel abarbeiten... richtig?

[Kamel]

Genau. Das single vs. multi bezieht sich nur auf den Client. Allerdings wurde in der Aufgabenstellung garnicht spezifiziert, ob der Server single- oder multithreaded ist...