Java + RMI Synchronisatie probleem

[Rempage0611]

Ok, ik heb dus een server en een client die met java met elkaar praten, voor zover geen probleem.

De clients rekenen priem getallen uit, sturen ze naar een Bag en de server verzamelt deze getallen uit de Bag.

Hier een paar stukjes code

De client die data verzend naar de "Task Bag"

code:

while ( !myServerObject.pairOut("ClientPrimes",NewPrimeNumbers)&&!myServerObject.allWorkDone())
                 {
                 Thread.sleep(10);
                 System.out.println("Sleeping until work can be handed in");
                 }

Stukjes Bag code

Hiermee kunnen clients priem getallen naar de server sturen

code:

  public synchronized boolean pairOut(String Key, int[] Value)//Clients geven resutlaten terug
                {
                if (PrimeNumberPartDone&&Key.equals("ClientPrimes"))
                   {
                   PrimeNumberPart=Value;
                   PrimeNumberPartDone=false;
                   return true;
                   }
                else return false;
                }

Hiermee haalt de server de priem getallen op

code:

    public int[] pairIn(String Key)
                {
                if (Key.equals("Primes"))                   {
                   return PrimeNumberPart;
                   }
                else return null;
                }

Stukjes server code:

code:

PrimeNumberPart=implementation.pairIn("Primes");
implementation.setPrimeNumberPartDone(true);

De client zend zijn data dus naar de bag, de bag kijkt of PrimeNumberPartDone true is, en copiert de data, als PrimeNumberPartDone false is, stuurt hij false terug en moet de client wachten.

Als de server met de pairIn data ophaald, zet hij hierna de PrimeNumberPartDone weer op true zodat er nieuwe data kan worden verzonden vanuit de clients..

Het probleem is nu dat de server data verliest, als ik later de reeks opgehaalde priem getallen naloop missen er echt een heleboel. Er runnen normaal 10 threads tegelijk, als ik er hier 1 van maak mis ik nog maar een paar stukjes, de clients overspoelen dus de bag/server.

Ik snap _niet_ hoe dit kan, ik zie het niet. Misschien is het iets heeeel stoms ofzo, maar ik wordt er gek van.

Wie weet mijn (stomme) fout te vinden? Bedankt!

[Alarmnummer]

Het is wat bij me opkomt bij dit soort problemen is waar de concurrency nou precies plaats vindt. En dat is dus de plek op de server waar alle getallen in geplaatst worden door de ophaal threads. Is die structuur wel threadsafe?

[Rempage0611]

Alarmnummer schreef op 27 March 2003 @ 16:24:
Het is wat bij me opkomt bij dit soort problemen is waar de concurrency nou precies plaats vindt. En dat is dus de plek op de server waar alle getallen in geplaatst worden door de ophaal threads. Is die structuur wel threadsafe?

Als ik je goed begrijp vraag je je af of het ophalen niet fout gaat door gebruik van meerdere threads.

De server is in z`n eentje, er is dus maar 1 thread die de priems ophaald.
Bedoel je dat?

[momania]

Rempage0611 schreef op 27 March 2003 @ 16:59:
[...]


Als ik je goed begrijp vraag je je af of het ophalen niet fout gaat door gebruik van meerdere threads.

De server is in z`n eentje, er is dus maar 1 thread die de priems ophaald.
Bedoel je dat?

Wat Alarmnummer volgens mij bedoeld is dat de variabele PrimeNumberPart misschien vanuit een client vaker wordt gevult dat dat hij door het server gedeelte wordt leeggehaald.
De pairOut methode vult nml. die array niet aan maar vult em opnieuw en daarmee gaat dus de oude data die in die array staat verloren.

[Rempage0611]

momania schreef op 27 March 2003 @ 17:09:
[...]

Wat Alarmnummer volgens mij bedoeld is dat de variabele PrimeNumberPart misschien vanuit een client vaker wordt gevult dat dat hij door het server gedeelte wordt leeggehaald.
De pairOut methode vult nml. die array niet aan maar vult em opnieuw en daarmee gaat dus de oude data die in die array staat verloren.

Daarvoor is de boolen PrimeNumberPartDone. Als de array niet leeg is, dan is deze boolean false en stuurt de bag false terug naar de server. Pas als de array geleegd is wordt PrimeNumberPartDone true en kan de client een nieuwe set primes versturen.

[Alarmnummer]

In wat voor structuur plaats je de berekende priemgetallen? Is deze structuur wel thread-safe? Jouw server die heeft als ik je verhaal goed begrijp meerdere threads in zich, en je hebt een structuur die door die threads wordt aangesproken. Dit is 1 goed argument om aan concurrency problemen te denken als je zomaar items verliest.

Stel je hebt een printer queue die nog leeg is. Printer1 komt eraan en wil graag een job plaatsen. Je vraagt aan de printerqueue welke plek leeg is, en dat is 0. Voordat Printer1 zijn job er in heeft geplaatst komt printer 2 eraan, en die vraagt nu aan de queue welke plaats leeg is, en dat is nog steeds 0. Printer2 zet zijn job op plaats 0 en nu komt de scheduler er weer aan, en geeft printer 1 weer de beurt. DIe had nog in zijn geheugen dat plaats 0 vrij was, dus die schrijft zijn job op plaats 0, over die andere job heen => concurrency problemen.

Zo gauw je data hebt dat tussen meerdere threads wordt gebruikt, dan moet je gaan denken aan concurrency control anders krijg je dit onverklaarbaar gedrag (dit heet ook wel een race probleem).

zie: http://developer.java.sun.com/developer/Books/performance2/ voor 2 uitstekende hoofdstukken waarin concurrency control aan bod komt.

[ Voor 20% gewijzigd door Alarmnummer op 27-03-2003 22:12 ]

[Rempage0611]

Ik begrijp wat je bedoelt maar imho is dat hier niet het geval (je mag slaan als het wel zo is )

De server is maar 1 thread, de clients zijn er meerdere. Het verhaal van die queue is duidelijk. Hier lijkt het inderdaad sterk op maar het kan volgens mij niet. PrimeNumberPartDone geeft aan de clients door of ze de data mogen neerzetten, dus het race effect zou hiet niet an toepassing zijn. Toch?

[momania]

Rempage0611 schreef op 28 March 2003 @ 13:04:
PrimeNumberPartDone geeft aan de clients door of ze de data mogen neerzetten, dus het race effect zou hiet niet an toepassing zijn. Toch?

Je kan het volgens mij beter zo implementeren dat de clients altijd hun data kwijt kunnen, ongeacht de status van de server.
Aan de serverkant moet je dan een threadsave methode hebben die de data toevoegd aan een treadsave object (denk hierbij aan een Vector, of andere objecten uit het collection framework die je zelf threadsave kan maken)
Aan de hand van de size van de vector en een losse thread, kan je dan die vector weer uitlezen om de data daarin verder te gaan gebruiken.