HELP --> Java vraagje.....

[apeldoorn]

Kep een java vraagje, je hebt een klasse Rekening

public class Rekening
{
public double saldo;

public Rekening (double beginsaldo)
{
saldo = beginsaldo;
}

public synchronized void boek (double bedrag)
{
saldo += bedrag;
}

public synchronized void maakOver (double bedrag, Rekening naar)
{
boek(-bedrag);
naar.boek(bedrag);
}
}

Kan iemand mij vertellen of deze klasse problemen geeft bij het parallel uitvoeren van de methoden van de klasse rekening. Volgens mij namelijk niet, maar voglens het antwoordenmodel treedt er dus een deadlock op. Zijn er slimmeriken die met zekerheid mij het antwoord kunnen vertellen???

is dit niet JavaScript?

[apeldoorn]

euhm, nee...maar lijkt er wel beetje op

[Chimera]

Yup. Hij locked zichzelf, en locked daarna het 'naar' object. Als dit 'naar' object tegelijkertijd hetzelfde doet heb je een deadlock.

[Chimera]

McLaren schreef:
is dit niet JavaScript?

*SPANK*

[apeldoorn]

Chimera schreef:
Yup. Hij locked zichzelf, en locked daarna het 'naar' object. Als dit 'naar' object tegelijkertijd hetzelfde doet heb je een deadlock.

Ik ben het er niet mee eens

Hij lockt niet het object, want je synchroniseert alleen de methode, en niet het gehele object.

Stel je voor dat je 2 threads hebt. Beide treads roepen op hun eigen "rekening" de methode maakover aan.
BV: thread1 : maakOver(100, rek2);
BV: thread2 : maakOver(100, rek1);

rekening 1 en 2 kunnen nu niet meer gebruikt worden tot maakOver klaar is.
MaakOver boekt, die ook synchronized is. Dus alle volgende oproepen wachten tot boek is afgelopen. Maar boek roept niets anders aan dat synchronized is, en zal altijd eindigen.
Dit geldt voor zowel boek op van en op naar, dus maakOver zal altijd eindigen. Daarna wordt het lock vrijgegeven, dus geen deadlock toch?!?!


[Dit bericht is aangepast door apeldoorn (30-01-2002).]

[Chimera]

Eerst object is compleet afgesloten op 't moment dat een synch method aangeroepen wordt. Als dan voor 'naar' een synch meth aangeroepen wordt, heeft een gelocked object een lock op een ander object, dat een lock kan aanvragen op object 1. Deadlock-gevaar dus.

Dat jij het er niet mee eens bent doet weinig ter zake, zo werken synched methods in Java.

[apeldoorn]

Dus jij weet 100% zeker als je een synchronized methode aanroept, dat hij dan gelijk het gehele Object lockt?? Volgens mij is dat namelijk niet waar...

[Chimera]

Hij locked in ieder geval die methodes, wat nog meer gelocked wordt is afhankelijk van welke methoden en members aangeroepen worden. Maar dat doet verder ook niet ter zake.

[apeldoorn]

Mmm....ik ben hardleers

Zou je kunnen zeggen wat hier fout aan is (deze beredenatie):

De methode boek "loopt nooit vast". Als er meerdere threads erin willen, wachten ze netjes op elkaar. De methode maakOver kan probleem geven, omdat die tijdens de executie moet wachten op boek (omdat al een andere thread ermee aan de slag is). Dus maakOver zit vast, en boek zit vast. Boek komt echter altijd vrij, dus er komt een moment dat ook maakOver zeg maar weer vrij komt. Er komt dus nooit een situatie waarin een deadlock optreedt...

Wat is er nu dan fout aan mijn redenatie...ik snap het niet....

[Chimera]

Threads wachten niet netjes. Als Thread A en B (Met rekening 1 en 2) tegelijkertijd bezig gaan, en tegelijkertijd geld overboeken (Rekening 1 -> 2 en vice-versa) dan krijg je een deadlock.

[apeldoorn]

Chimera schreef:
Threads wachten niet netjes. Als Thread A en B (Met rekening 1 en 2) tegelijkertijd bezig gaan, en tegelijkertijd geld overboeken (Rekening 1 -> 2 en vice-versa) dan krijg je een deadlock.

Okay, ik snap hem geloof ik . Bedankt voor de support slimme Chimera

[Chimera]

apeldoorn schreef:

Okay, ik snap hem geloof ik . Bedankt voor de support slimme Chimera

NP

Is dit voor school BTW? We hebben er een heel vak over gehad, concurrent programming. Best leuk, threads kunnen hele vage dingen doen

[apeldoorn]

Chimera schreef:
NP

Is dit voor school BTW? We hebben er een heel vak over gehad, concurrent programming. Best leuk, threads kunnen hele vage dingen doen

Ja, was voor school. Wij behandelen elke week 1 onderwerp m.b.t. programmeren in java vrij globaal. Alleen wij werken met een erg amateuristisch boek ("Object oriented programming in Java" van Martin Kalin (Depaul University)). Er staan me een fouten in... Onder andere dat ze een stukje code in een klasse synchroniseren met een lock object, terwijl dat lock object zeg maar bij elke thread uniek is. Dus dan klopt er weer geen bout van.

In dat boek stond dus ook, als je bv. 2 methoden synchroniseert en als dan 1 object de ene methode in komt, dat dan nog een ander object de ander gesynchroniseerde methode in kan. Daarom dacht ik dus ook dat er geen deadlock kon optreden. Ik kwam er gelukkig nog vlak voor tentamen achter, dat dan gelijk het gehele object gelockt is...

Maar we zullen het vast ook nog wel eens een stuk uitgebreider krijgen. En het tentamen was vrij simpel gelukkig .

Thanks for the support in ieder geval, ik hoop dat ik ooit nog eens zo slim wordt als jij

[Chimera]

apeldoorn schreef:

Thanks for the support in ieder geval, ik hoop dat ik ooit nog eens zo slim wordt als jij

Slijmbal

Valt tegen. Had nu al bezig moeten zijn met afstuderen

[apeldoorn]

Chimera schreef:
Slijmbal

Ach, je moet toch iets zeggen om je te vleien voor een volgende keer als ik vsat zit met java