[java] Threads

[Verwijderd]

Heej,

Ik ben geen goeroe als het gaan om java, ik kom meer in de buurt van een 'noebie'... (newby dus!)

Anyways, als je 2 threads hebt; 2 auto's op een al dan niet visueel kruispunt die beiden willen oversteken. Auto1 steekt eerder over dan auto2.
Ik heb dan in m'n hoofd dat er een soort van globale variable gevuld wordt met 'Ik steek over, niemand anders!' (oversteken = 0). Goed, auto1 steekt over. Maar, hoe weet auto2 diezelfde variable uit te lezen, zodat hij weet dat hij niet kan oversteken?

M'n vraag is dus kort; Bestaat er binnen java iets dat 2 threads 1 variable of geheugenplaats uit kunnen lezen? Dus soort 'opper-globale variable' of zo?

Thanx!

[Verwijderd]

probeer eens een synchronized functie.

[MisterData]

Moest dat niet met het keyword volatile Dat iets vanuit 2 threads toegankelijk is ? Anyway,je zult hemsynchronized moeten maken, aangezien het niet de bedoeling is dat auto 1 en auto 2 tegelijk het kruispunt kunnen 'locken'. Synchronizen dus

[D2k]

mutexen

[MisterData]

Op dinsdag 02 april 2002 14:15 schreef D2k het volgende:
mutexen

Java Mutex

[D2k]

Op dinsdag 02 april 2002 14:16 schreef MisterData het volgende:

[..]

Java Mutex

D2k != Java goeroe
D2k == theoretisch onderbouwd
--------------------------------+
correct antwoord, implementatie onbekend

[Alarmnummer]

code:

class Kruispunt{
    public synchronized steekOver(Auto auto){
      ...doe iets.
    }
}

Door synchronized te gebruiken voor de methode naam, garandeer je dat er ten hoogste 1 thread binnen kruispunt actief is.

[Alarmnummer]

Op dinsdag 02 april 2002 14:13 schreef MisterData het volgende:
Moest dat niet met het keyword volatile Dat iets vanuit 2 threads toegankelijk is ?

Auto1 en auto2 kunnen gewoon het kruispunt object aanroepen. Daar hebben ze helemaal geen volatile voor nodig. Ik ben er zelf niet echt in thuis, maar volatile zorg ervoor dat java objecten waarden niet uit de cache gaan halen maar altijd vers uitlezen. Maar een volatile waarde is zeker geen oplossing, daarvoor heb je concurrency control nodig. (anders krijg je race condities).

Anyway,je zult hemsynchronized moeten maken, aangezien het niet de bedoeling is dat auto 1 en auto 2 tegelijk het kruispunt kunnen 'locken'.

Als er op een object een ongesychroniseerde methode aanroep wordt gedaan, dan is er geen sprake van een lock. Wat jij bedoelt is dat 2 threads tegelijk 1 methode kunnen uitvoeren.

Synchronizen dus

Daar ze we het in ieder geval over eens

[Soultaker]

En voor de theoretisch onderbouwden onder ons: een syncronized method staat in alle overige programmeertalen bekend als een critical section.

Op assembly nivo ondersteund Java ook monitors, waarmee zowel mutual exclusion (mutex) te implementeren is, als een soort van semaphore, waarbij de ene thread wacht tot een andere een notification stuurt.

Ik heb geen idee of dit soort mechanismen ook in de API geimplenteert zijn (ik ben ze nooit tegengekomen, maar ik heb dan ook nooit veel met Java gewerkt).

Een groot nadeel van syncronized methods vind ik dat ze bijna altijd meer statements omvatten dan strict noodzakelijk. Meestal wil je slechts een deel van de functie gesynchroniseerd uitvoeren en kan de initialisatie enzo wel parallel uitgevoerd worden. Je zou dan een kleine private methode kunnen creëeren om je critical section beperkt te houden, maar conceptueel is dat niet zo mooi. Ik had zelf liever een syncronized keyword gezien zoals je ook try-catch hebt, dus bijvoorbeeld zoiets:

code:

public void voorbeeld()
{
  Voorbeeld a=getIets();
  syncronized {
    if(a.blaat()<nogIets())
    return;
    a.blabla();
  }
  setIets(a); 
}

Verder is het zo dat de huidige vorm van synchronisatie objecten locked, in plaats van secties. Het kan dus zo zijn dat er een methode 'aaa' bestaat die slechts door één thread mag worden aangeroepen en een onafhankelijke methode 'bbb' met dezelfde eigenschap. Conceptueel gezien zouden 'aaa' en 'bbb' wel tegelijkertijd aangeroepen mogen worden, maar aangezien bij het aanroepen van een van de twee methoden het object in zijn geheel gelocked is, is dit in Java onmogelijk.

Behalve dat dit logischerwijs nog meer performanceverlies met zich meebrengt, omdat threads onnodig op elkaar zitten te wachten, kan het ook onverwachte deadlocks veroorzaken die met goed gedefinieerde critical sections niet zouden kunnen optreden. Denk hierbij aan een implementatie van 'aaa' die eeen ander object aanroept, die vervolgens 'bbb' van hetzelfde object wil aanroepen. Conceptueel gezien zou dit altijd moeten kunnen, maar in Java levert dit hoogstwaarschijnlijk een deadlock op.

Disclaimer: ik heb geen van dit alles getest, dus als ik 't mis heb, geef me er maar van langs.

[Alarmnummer]

Je bedoelt dit denk ik:

code:

public void voorbeeld()
{
  Voorbeeld a=getIets();
  syncronized (this){<<==
    if(a.blaat()<nogIets())
    return;
    a.blabla();
  }
  setIets(a); 
}

En verder kan je zelf semaphoren en monitoren maken mbv synchronized code/methodes.

[Soultaker]

Op dinsdag 02 april 2002 15:00 schreef Alarmnummer het volgende:
Je bedoelt dit denk ik:

code:

public void voorbeeld()
{
  Voorbeeld a=getIets();
  syncronized (this){<<==
    if(a.blaat()<nogIets())
    return;
    a.blabla();
  }
  setIets(a); 
}

Ah, bedankt! Dat wist ik niet. Jammer dat dat niet in de tutorial trails aan de orde komt.

En verder kan je zelf semaphoren en monitoren maken mbv synchronized code/methodes.

Natuurlijk, maar een standaardklasse was wel handig geweest, aangezien dit basisbouwstenen zijn die waarschijnlijk in veel threadbased applicaties nodig zijn.

[Alarmnummer]

Op dinsdag 02 april 2002 14:58 schreef Soultaker het volgende:
En voor de theoretisch onderbouwden onder ons: een syncronized method staat in alle overige programmeertalen bekend als een critical section.

Volgens mij is dat een algemeen begrip en niet zozeer iets van een programmeer taal.

Behalve dat dit logischerwijs nog meer performanceverlies met zich meebrengt, omdat threads onnodig op elkaar zitten te wachten,

Zie mijn vorige antwoord met

synchronized(this){
...critical section
}

voor opl.

kan het ook onverwachte deadlocks veroorzaken die met goed gedefinieerde critical sections niet zouden kunnen optreden.

Ik ben mijn kennis aan het opfrissen en een simpel concurrency control opdrachtje is niet zo`n probleem. Maar wat ik lastig vind is om in grotere api`s alles goed voor elkaar te krijgen ivm deadlocks.

Denk hierbij aan een implementatie van 'aaa' die eeen ander object aanroept, die vervolgens 'bbb' van hetzelfde object wil aanroepen. Conceptueel gezien zou dit altijd moeten kunnen, maar in Java levert dit hoogstwaarschijnlijk een deadlock op.

je bedoelt misschien dit?

code:

class Banaan{
   public synchronized void actie1(){
     actie2();
   }
   
   public synchronized void actie2(){
   }
}

Dit leverd geen problemen op.

uitleg:
Thread1 die komt eraan en roept actie1 aan. Er wordt pas verder gegaan als hij een lock krijgt op Banaan. Zo gauw dit lukt gaat hij beginnen met actie2. Aangezien Thread1 al de lock heeft, mag hij hier gewoon mee verder gaan en is uiteindelijk klaar met actie2, en daarna met actie1 en geeft zijn lock weer op.

link voor leuk tutorial:
http://developer.java.sun.com/developer/Books/performance2/
daar staat ook wel een semaphore in

[Alarmnummer]

En voor een goed boek voor java (die ik nu aan het doorploegen ben) zie: http://s1.amazon.com/exec/varzea/ts/exchange-glance/Y01Y6985699Y4498073/qid=1017753800/sr=1-2/103-2225011-7198242

Van onze grote vriend Doug Lee

[Soultaker]

Op dinsdag 02 april 2002 15:20 schreef Alarmnummer het volgende:
je bedoelt misschien dit?

code:

class Banaan{
   public synchronized void actie1(){
     actie2();
   }
   
   public synchronized void actie2(){
   }
}

Dit leverd geen problemen op.

Uiteraard niet, zoals je al uitlegt. Het gaat pas fout als een andere thread als gevolg van actie1 actie2 probeert aan te roepen, maar in tegenstelling tot wat ik beweerde, komt dit zelden voor, dus dat is niet zo'n groot bezwaar. De problemen vallen in de praktijk dus wel mee.

Verder zag ik in jou code dat synchronized ook een specifiek object kan locken. Waarschijnlijk kun je de genoemde problemen dan ook wel zo oplossen:

code:

class MijnKlasse
{
  Object mutex=new Object();

  public void mijnMethode()
  {
     ...
     synchronized(mutex)
     {
      ...
     }
     ...
  }

Dat is natuurlijk wel weer een nette oplossing, omdat je nu gewoon een mutex hebt gemaakt. In veel gevallen zal je een 'echt' object voor mutex kunnen gebruiken natuurlijk, hoewel het niet mogelijk is om meerdere objecten te locken op deze manier. Een mogelijkheid is:

code:

syncronized(a) { syncronized (b) {
  ...
} }

Maar dit ziet er ten eerste niet zo mooi uit en is niet hetzelfde als meerdere objecten tegelijk locken, aangezien b alsnog door een andere thread gelocked kan worden zolang a nog niet gelocked is door de huidige thread. Als in een ander stuk code a en b omgewisseld worden krijg je een deadlock. Of is hier ook een oplossing voor?

[Alarmnummer]

Ik denk dat we nu toch wel snel naar een monitor moeten grijpen omdat je anders een oncontroleerbaar geheel gaat krijgen ivm deadlocks ed

want het is lastig om te garanderen dat als

synchronized(a){
...synchronized(b){
...}
}

zich voordoet, dat
synchronized(b){
...synchronized(a){
...}
}

zich niet ergens anders voordoet.

en het wordt helemaal complex als nog een c,d,e,f,g,h,i en j er bijkomen

[ACM]

Op dinsdag 02 april 2002 14:16 schreef MisterData het volgende:
Java Mutex

Daar bestaan wel degelijk classes voor in Java, zou nog wel es de naam Mutex kunnen hebben ook

Maar de synchronized oplossing is in de meeste gevallen wel voldoende

[Alarmnummer]

Zover ik weet heeft java verder geen concurrency control classes. Je zult echt alles zelf moeten maken.

In de onderstaande link staan wel een aantal objecten:
oa locks, semaphoren en uitleg over monitoren.

http://developer.java.sun.com/developer/Books/performance2

[ACM]

Op dinsdag 02 april 2002 16:12 schreef Alarmnummer het volgende:
Zover ik weet heeft java verder geen concurrency control classes. Je zult echt alles zelf moeten maken.

Niet binnen de echte java api nee, maar die classes die ik bedoel komen waarschijnlijk wel in de API (als ik mbravenboer mag geloven en dat doe ik in dezen maar )

[Alarmnummer]

Op dinsdag 02 april 2002 16:13 schreef ACM het volgende:

[..]

Niet binnen de echte java api nee, maar die classes die ik bedoel komen waarschijnlijk wel in de API (als ik mbravenboer mag geloven en dat doe ik in dezen maar )

Dan is het de lib van Doug Lee

[ACM]

Op dinsdag 02 april 2002 16:15 schreef Alarmnummer het volgende:
Dan is het de lib van Doug Lee

Geloof het wel ja

Maar ik heb het nooit zo goed bekeken, ik kreeg een link naar die package van mbravenboer terwijl ik 1 simpele methode eruit nodig had (de 'timed wait') en meer niet

[Alarmnummer]

Ik ben nu het boek van hem aan het doorlezen om mijn kennis op te frissen en te verhogen. Als je met java en concurrency bezig moet, is dit boek wel een aanrader.

[Verwijderd]

ik heb een beetje hetzelfde probleem als predatorx

maar aangezien ik weinig (tot nix) kan met java.. zou 1 van jullie een klein (werkend) voorbeeld kunnen laten zien van het probleem van predatorx!

ik loop hier echt hopeloos mee vast....!

Alvast bedankt!

The Predator

[Alarmnummer]

code:

class Kruispunt{
    public synchronized void steekOver(Auto auto){
      ...doe iets.
    }
}

en als je weinig tot niets kan met java moet je <h1>[fucking groot bold]NIET[/fucking groot bold]</h1> met threads bezig gaan.

_{D2k edit}

[D2k]

en stukjes source posten doen we hier niet
lees de faq/quickguide maar eens