[JAVA] Thread probleem

[Verwijderd]

Zie hier mijn test code:

code:

import java.io.*;

public class ThreadTest extends Thread {
    private String id;

    public ThreadTest(String id) {
      this.id = id;
    }

    public void run() {
      try {
        BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
        String readLine = "";
        String input = "";
        System.out.println("Thread: " + id + " is waiting for input. Stop feed with '.'");
        while (!readLine.equals(".")) {
            readLine = reader.readLine();
            input += readLine;
        }
        System.out.println("Thread: " + id + " stopped feed.");
      } catch (IOException e) {
        System.out.println("IO exception: " + e.getMessage());
      }
    }

    public static void main (String args[]) {
      ThreadTest a = new ThreadTest("A");
      ThreadTest b = new ThreadTest("B");

      a.start();
      b.start();
    }

}

Het programma doe niet wat ik verwachtte. Ik wil namelijk dat wanneer Thread B gestart wordt de while loop van B eerst helemaal doorlopen wordt tot dat de user een '.' typt. Vervolgens moet thread A verder gaan. Nu lopen beiden threads tegelijk... En A wordt eerst afgerond voordat B afgerond wordt.. Dit wil ik niet ... Ik wil dat eerst B afgerond wordt vervolgens A.


Kan iemand mij:
a) vertellen waarom mijn code niet werkt
b) vertellen hoe ik het opgelost krijg zodat het wel werkt
?

Bedankt!

[Janoz]

Wat gaat er fout? Compileert het niet?

[Verwijderd]

Op vrijdag 21 december 2001 20:04 schreef Janoz het volgende:
Wat gaat er fout? Compileert het niet?

B komt niet aan de beurt omdat A er nog steeds is... Ik wil dat B eerst helemaal afgerond wordt voordat A weer aan de beurt is...

Compile het voorbeeldje anders even. Dan is het je meteen duidelijk.

[D2k]

ik weet niet veel van threads behalve dan dat ze in C gewoon simultaan lopen. Dat is volgens mij ook het voordeel van threads

correct me if i'm wrong

[Janoz]

Laat eens een voorbeeld van de output zien?

[Verwijderd]

Op vrijdag 21 december 2001 20:18 schreef D2k het volgende:
ik weet niet veel van threads behalve dan dat ze in C gewoon simultaan lopen. Dat is volgens mij ook het voordeel van threads

correct me if i'm wrong

Ok voor de duidelijkheid... Ik heb een programma gemaakt wat een Console klasse heeft... De instantie van deze klasse doet niets anders dan user input verwerken.(Thread 'A') (Vergelijk het met een UNIX-shell). Vervolgens tikt de user een data commando in. Er wordt dan een instantie van een klasse geladen die precies hetzelfde doet, alleen zorgt deze klasse er niet voor dat de userinput verwerkt wordt als commando's maar als 'invoerdata'. (Dit is Thread 'B').

Beide gebruiken ze de standaard input (System.in).
Maar ik wil dat wanneer Thread B loopt (de data-thread), Thread A niet interruppeerd (De Console klasse).

Natuurlijk lopen Thread simultaan... Maar ik wil dat deze blokken code gesynchroniseerd verwerkt worden. Dus, eerst B afwerken voordat A verder mag gaan met het verwerken van commando's. In werkelijkheid is het programma vele malen groter en lopen er enkele tientallen threads.

[mbravenboer]

razor_harm: Ik wil namelijk dat wanneer Thread B gestart wordt de while loop van B eerst helemaal doorlopen wordt tot dat de user een '.' typt.

Hoe kom jij er dan bij dat je dit verwacht? Merk een belangrijk feit op: de code van beide Threads is exact hetzelfde. Het is daarom [i]onmogelijk]/i] om deterministisch gedrag te verwachten. Hoe kan thread B ooit anders werken dan thread A als de code exact hetzelfde is?

Merk ook op dat er geen enkele garantie is dat Thread B uberhaupt aan bod komt. Het is heel goed mogelijk dat eerst heel Thread A wordt afgewerkt en pas daarna Thread B of andersom.

Nu lopen beiden threads tegelijk... En A wordt eerst afgerond voordat B afgerond wordt.. Dit wil ik niet ... Ik wil dat eerst B afgerond wordt vervolgens A.

Ik zie echt niet in je code hoe je dat dan had gedacht te regelen...

Als je eerst B wilt afhandelen voor A zou je aan het begin van Thread B thread A kunnen joinen. Maar waarom uberhaupt met Threads werken als ze achter elkaar uitgevoerd moeten worden .

a) vertellen waarom mijn code niet werkt

Ik hoop dat dat gelukt is .

b) vertellen hoe ik het opgelost krijg zodat het wel werkt

Tja, dan zou ik toch eerst iets meer over het doel moeten weten. Waarom werk je met Threads als je sequentieel wilt werken?

Misschien moet je eens goed kijken wat Thread precies zijn en hoe het gedrag van Threads is gedefinieerd. Ook moet je wel iets weten over monitoren, wait, notify, notifyAll etc voordat je echt serieus met Threads aan de slag kunt .

Als je je echt goed in concurrent programming wilt verdiepen kan ik je 1 boek zeer sterk aanraden:
"Concurrent Programming in Java, Second Edition: Design Principles and Patterns" door de guru himself: Doug Lea.

Met de Java Tutorial kan je ook vast wel het een en ander oplossen:
http://java.sun.com/docs/books/tutorial/essential/threads/index.html

[D2k]

mutex gebruiken

<edit>
dit kan toch ook martin?

[D2k]

mbravenboer: Hoe kom jij er dan bij dat je dit verwacht? Merk een belangrijk feit op: de code van beide Threads is exact hetzelfde. Het is daarom [i]onmogelijk]/i] om deterministisch gedrag te verwachten. Hoe kan thread B ooit anders werken dan thread A als de code exact hetzelfde is?

ja ik d8 ook al wat wil die nou?

Merk ook op dat er geen enkele garantie is dat Thread B uberhaupt aan bod komt. Het is heel goed mogelijk dat eerst heel Thread A wordt afgewerkt en pas daarna Thread B of andersom.

eigenschap van threads

Ik zie echt niet in je code hoe je dat dan had gedacht te regelen...

Als je eerst B wilt afhandelen voor A zou je aan het begin van Thread B thread A kunnen joinen. Maar waarom uberhaupt met Threads werken als ze achter elkaar uitgevoerd moeten worden .

tja hij was mij ook al kwijt

Ik hoop dat dat gelukt is .

jou lukt dat altijd

Tja, dan zou ik toch eerst iets meer over het doel moeten weten. Waarom werk je met Threads als je sequentieel wilt werken?

Misschien moet je eens goed kijken wat Thread precies zijn en hoe het gedrag van Threads is gedefinieerd. Ook moet je wel iets weten over monitoren, wait, notify, notifyAll etc voordat je echt serieus met Threads aan de slag kunt .

Als je je echt goed in concurrent programming wilt verdiepen kan ik je 1 boek zeer sterk aanraden:
"Concurrent Programming in Java, Second Edition: Design Principles and Patterns" door de guru himself: Doug Lea.

Met de Java Tutorial kan je ook vast wel het een en ander oplossen:
http://java.sun.com/docs/books/tutorial/essential/threads/index.html

idd gewoon sequentieel als je echt zeker de volgorde wil garanderen

[mbravenboer]

Je moet trouwens sowieso onwijs uitkijken omdat je met 2 threads van dezelfde InputStream leest... Ik weet zo eigenlijk niet hoe het gedrag dan is gespecificeerd. Ik vermoed dat diegene die het eerst leest (A dus!) ook het eerst aan bod komt...

[mbravenboer]

Hum ik zie je probleem nu beter:

Je ziet de vraag van B verschijnen, maar als je een punt tikt reageert A... Dat komt omdat je in feite op dezelfde InputStream zit. Kennelijk gedraagd deze zich zo: diegene die het eerst leest, krijgt het eerst antwoord.

[Verwijderd]

Op vrijdag 21 december 2001 20:27 schreef D2k het volgende:

[..]

ja ik d8 ook al wat wil die nou?
[..]

eigenschap van threads
[..]

tja hij was mij ook al kwijt
[..]

jou lukt dat altijd
[..]

idd gewoon sequentieel als je echt zeker de volgorde wil garanderen

Volgens mij is het probleem niet helemaal duidelijk...
Alle twee de threads gebruiken hetzelfde object (System.in).

De user typt dus iets in... Maar weet nooit in welke thread zijn data verwerkt wordt. Ik wil dat een stuk van de code gesynchroniseerd verwerkt wordt. (Een soort van mutex).
Dus, eerst helemaal de while-lus van B verwerken voordat A weer aanspraak kan maken op het System.in object...

[Verwijderd]

Op vrijdag 21 december 2001 20:30 schreef mbravenboer het volgende:
Hum ik zie je probleem nu beter:

Je ziet de vraag van B verschijnen, maar als je een punt tikt reageert A... Dat komt omdat je in feite op dezelfde InputStream zit. Kennelijk gedraagd deze zich zo: diegene die het eerst leest, krijgt het eerst antwoord.

Jij snapt 'm !

Weet je ook hoe ik kan oplossen??? Zie ook vorige bericht, btw

[corani]

Op vrijdag 21 december 2001 20:32 schreef razor_harm het volgende:

[..]

Jij snapt 'm !

Weet je ook hoe ik kan oplossen??? Zie ook vorige bericht, btw

Zomaar een los idee.. Als je klaar bent met lezen in een thread, je reader deleten?

[Verwijderd]

Ik dacht dat ik het met het synchronized keyword iets aan kon doen door de while loops te synchroniseren.

dus zoiets:

[code]

synchronized (System.in) {
// while loop
}

Maar dat werkt ook niet...

[Verwijderd]

Op vrijdag 21 december 2001 20:35 schreef corani het volgende:

[..]

Zomaar een los idee.. Als je klaar bent met lezen in een thread, je reader deleten?

Dat zou kunnen, probleem is alleen dat A een thread is die nooit klaar is met lezen... Ik kan de reader dus niet deleten. De A thread is een soort UNIX shell waarbij de user commando's in moet tikken (En moet dus continue draaien). Bij B zou dat wel kunnen overigens...

[corani]

Op vrijdag 21 december 2001 20:37 schreef razor_harm het volgende:

[..]

Dat zou kunnen, probleem is alleen dat A een thread is die nooit klaar is met lezen... Ik kan de reader dus niet deleten. De A thread is een soort UNIX shell waarbij de user commando's in moet tikken (En moet dus continue draaien). Bij B zou dat wel kunnen overigens...

In dat geval moet je misschien een eigen reader schrijven.. Ik heb het niet bestudeerd, maar het lijkt me anders onmogelijk dat twee threads van de zelfde invoer kunnen lezen.

[Verwijderd]

Op vrijdag 21 december 2001 20:39 schreef corani het volgende:

[..]

In dat geval moet je misschien een eigen reader schrijven.. Ik heb het niet bestudeerd, maar het lijkt me anders onmogelijk dat twee threads van de zelfde invoer kunnen lezen.

Dat lijkt me niet... Dit is een veel voorkomend probleem. Dat weet ik vrijwel zeker. In de QT libraries (C++) is dit oplosbaar met een mutex. Alle threads moeten dan wachten totdat de thread die de mutex heeft klaar is met het object te gebruiken. Dat moet in Java zeker ook kunnen... Vraag is alleen hoe...

[mbravenboer]

D2k: mutex gebruiken

Java kent alleen maar monitoren, maar je kunt wel een mutex implementeren met een monitor .

Zie hier:
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html

en de website van het boek wat ik noemde:

http://gee.cs.oswego.edu/dl/cpj/

Het hangt er een beetje vanaf wat hij nu eigenlijk wil of een mutex nuttig is of niet...

[Verwijderd]

razor_harm, Ik weet niet op ik precies begrijp wat je bedoeld, maar ik geloof dat je een thread wil laten wachten op een andere thread? Dit is namelijk vrij simpel, en zal dus wel niet jouw vraag zijn geweest, maar toch:
try
{
b.join();
}
catch ( Exception e )
{;}
nu wacht de huidige thread, tot thread b klaar is.
Ow, ik zie nu dat je 2x met de system.in werkt, in dit geval zou ik synchronized opnemen.

[mbravenboer]

Er is maar 1 oplossing denk: een aparte Thread maken die van een InputStream leest en het gedrag van InputStream aanpast naar hetgene wat jij wil....

De huidige implementatie werkt als het ware met een Queue: first in, first out.... Je hebt in feite een Stack nodig: last in, first out.

Dit is meer een io probleem. Je zou het ook nog met non-blocking io kunnen oplossen...

[D2k]

mbravenboer : Java kent alleen maar monitoren, maar je kunt wel een mutex implementeren met een monitor .

ach jee weer een beperking
en dat terwijl threads toch over bijna alle OS-en zijn geimplementeerd

<ot>
heb je ook icq?
</ot>

[mbravenboer]

mbravenboer: Als je eerst B wilt afhandelen voor A zou je aan het begin van Thread B thread A kunnen joinen. Maar waarom uberhaupt met Threads werken als ze achter elkaar uitgevoerd moeten worden .

[Verwijderd]

Op vrijdag 21 december 2001 20:43 schreef Radiant1 het volgende:
razor_harm, Ik weet niet op ik precies begrijp wat je bedoeld, maar ik geloof dat je een thread wil laten wachten op een andere thread? Dit is namelijk vrij simpel, en zal dus wel niet jouw vraag zijn geweest, maar toch:
try
{
b.join();
}
catch ( Exception e )
{;}
nu wacht de huidige thread, tot thread b klaar is.

Dat is inderdaad niet het probleem... Het probleem is dat beide threads gebruik maken van hetzelfde object (System.in). Het komt er op neer dat A even moet stoppen met het System.in object te gebruiken totdat B er mee klaar is...

[Paul]

Dan moet je in A B starten, waarna je A laat waiten, en zodra B klaar is, notify je B. Waarom is me een raadsel, want inderdaad, dan ben je sequentieel bezig, en kun je net zo een methode aanroepen die exact hetzelfde doet als B. Als je voor die methode nu dezelfde gebruikt als voor A, ben je zelfs recursief bezig. Mits je dat niet te vaak doet (jezelf aanroepen, ivm stacks en zo) gaat dat wel goed, aangezien A nu niet meer van stdin leest.

[Verwijderd]

Als je eerst B wilt afhandelen voor A zou je aan het begin van Thread B thread A kunnen joinen. Maar waarom uberhaupt met Threads werken als ze achter elkaar uitgevoerd moeten worden?

Omdat er in mijn eigenlijke programma veel meer threads draaien... Enkele tientallen...
En ik nooit weet wanneer B opgestart wordt...
B wordt ook niet opgestart vanuit A, etc... Joinen is dus geen optie

[Verwijderd]

Op vrijdag 21 december 2001 20:45 schreef razor_harm het volgende:
Dat is inderdaad niet het probleem... Het probleem is dat beide threads gebruik maken van hetzelfde object (System.in). Het komt er op neer dat A even moet stoppen met het System.in object te gebruiken totdat B er mee klaar is...

In dat geval, Synchronized, kies wat je wil, maak heel de run Syncronized, of alleen de lees loop.
private Object o;
synchronized ( o )
{
je hebt nu de zogenaamde monitor lock, niets anders kan er nu aanzitten.
}

[mbravenboer]

D2k: eigenschap van threads

Inderdaad, ik heb opgelet bij m'n les .

ach jee weer een beperking

Mwah dat valt wel mee hoor . Download de Mutex implementatie maar eens. Is prachtig uitgedrukt met monitoren.

Het is gewoon een simplificatie keuze geweest: 1 threading model met monitoren, geen semaforen.

heb je ook icq?

Nope. ff niet. ICQ op Linux is vrij dood de laatste tijd .

[D2k]

mbravenboer:Inderdaad, ik heb opgelet bij m'n les .

blijkt
ik ben al een aantal weken bezig met thread onder linux en nog een hoop gekke dingen

Mwah dat valt wel mee hoor . Download de Mutex implementatie maar eens. Is prachtig uitgedrukt met monitoren.

Het is gewoon een simplificatie keuze geweest: 1 threading model met monitoren, geen semaforen.

tja niet standaard is gefaked
nee ik snap wat je bedoeld

Nope. ff niet. ICQ op Linux is vrij dood de laatste tijd .

ook everybuddy/licq?
of staat er op de site van icq geen linux kloon meer?

[mbravenboer]

Het probleem is geloof ik niet helemaal duidelijk. Het gaat precies hierom:

De huidige InputStream implementatie werkt als het ware met een Queue: first in, first out.... Je hebt in feite een Stack nodig: last in, first out.

Je moet dus zorgen dat de Thread die het laatste een readLine doet ook als eerste een resultaat krijgt. Dit kan je vrij eenvoudig oplossen met een vrij kleine eigen implementatie.

[mbravenboer]

D2k: ook everybuddy/licq?
of staat er op de site van icq geen linux kloon meer?

licq is bagger de laatste tijd... Uit frustratie heb ik hem tijdelijk uitgezet. Ik kan wel ergens op IRC komen als je wilt kletsen .

irc.tweakers.net
#javahova

[D2k]

Op vrijdag 21 december 2001 20:52 schreef mbravenboer het volgende:

[..]

licq is bagger de laatste tijd... Uit frustratie heb ik hem tijdelijk uitgezet. Ik kan wel ergens op IRC komen als je wilt kletsen .

hmmz voor we helemaal ot gaan
noem maar een plek
dan down ik ff een mirc client
</ot>

[Verwijderd]

Waarom werkt dit niet dan:

code:

import java.io.*;

public class ThreadTest extends Thread {
    private String id;
    private BufferedReader reader;

    public ThreadTest(String id) {
      this.id = id;
      reader = new BufferedReader(new InputStreamReader(System.in));

    }

    public void run() {
      synchronized (reader) {
        try {
            String readLine = "";
            String input = "";
            System.out.println("Thread: " + id + " is waiting for input. Stop feed with '.'");
            while (!readLine.equals(".")) {
              readLine = reader.readLine();
              input += readLine;
            }
            System.out.println("Thread: " + id + " stopped feed.");
        } catch (IOException e) {
            System.out.println("IO exception: " + e.getMessage());
        }
      }
    }

    public static void main (String args[]) {
      ThreadTest a = new ThreadTest("A");
      ThreadTest b = new ThreadTest("B");

      a.start();
      b.start();
    }

}

De blokken zijn nu gesynchroniseerd... Ik quote uit m'n Java Boek:

code:

synchronized (System.out) {
   for (int i = 0; i < 100; i++) {
    System.out.println("Number: " + i);
   }
}

This means that once one thread starts printing out the values, all other threads will have to stop and wait for it to finisch before they can print out their values.

[mbravenboer]

reader is een instantie variabele en je maakt twee instanties aan.... Het zijn dus twee verschillende 'reader' objecten.

Zal even een voorbeeld maken.

[Verwijderd]

Eh sorry... Dat laatste werkte dus wel... Het komt er op neer dat beide threads het System.in object moeten synchroniseren. In m'n test applicatie zijn beide threads nu gesynchroniseerd, in m'n echte applicatie waren ze dat niet...


Als een van de threads dus niet gesynchroniseerd is gaat het dus daarom mis!

Toch bedankt allemaal...

Was dus toch vrij eenvoudig, nietwaar jongens?

[mbravenboer]

Hier is er maar 1 reader Object en zal het synchronized block dus wel goed werken... Thread B zal waarschijnlijk wachten op Thead A, maar dit is niet (!) gegarandeerd. Het kan ook zijn dat Thread B eerst de monitor in gaat.

code:

import java.io.*;

public class ThreadTest extends Thread {
    private String id;
    private static BufferedReader reader;

    public ThreadTest(String id) {
      this.id = id;
    }

    public void run() {
      synchronized (reader) {
        try {
            String readLine = "";
            String input = "";
            System.out.println("Thread: " + id + " is waiting for input. Stop feed with '.'");
            while (!readLine.equals(".")) {
              readLine = reader.readLine();
              input += readLine;
            }
            System.out.println("Thread: " + id + " stopped feed.");
        } catch (IOException e) {
            System.out.println("IO exception: " + e.getMessage());
        }
      }
    }

    public static void main (String args[]) {
      reader = new BufferedReader(new InputStreamReader(System.in));

      ThreadTest a = new ThreadTest("A");
      ThreadTest b = new ThreadTest("B");

      a.start();
      b.start();
    }

}

[Verwijderd]

Op vrijdag 21 december 2001 21:02 schreef mbravenboer het volgende:
reader is een instantie variabele en je maakt twee instanties aan.... Het zijn dus twee verschillende 'reader' objecten.

Zal even een voorbeeld maken.

Dat dacht ik dus ook... Maar dat blijkt niet zo te zijn. Logisch eigenlijk omdat het gaat om 1 object (System.in)...

[Verwijderd]

Ik denk, dat dit is omdat je BufferedReader synched is, de instantie van de bufferedreader, deze is natuurlijk altijd free, omdat je hem iedere keer apart aanmaakt. Als je nu je system.in synchronized, dan zou het dus opgelost moeten zijn. Alle threads lezen tenlotte van de zelfde instantie van system.in. Hoop dat dit helpt.

[mbravenboer]

razor_harm: Dat dacht ik dus ook... Maar dat blijkt niet zo te zijn. Logisch eigenlijk omdat het gaat om 1 object (System.in)...

Nee, het is dus wel zo! Je maakt een synchronized block (monitor) over twee verschillende objecten... dat heeft dus geen nut. Wat ik zei klopte volledig.

In mijn voorbeeld is er maar 1 object en heeft het dus wel nut. Als je synchronized over System.in gaat het wel goed omdat je dan hetzelfde object gebruikt.

[Verwijderd]

Op vrijdag 21 december 2001 21:08 schreef mbravenboer het volgende:

[..]

Nee, het is dus wel zo! Je maakt een synchronized block (monitor) over twee verschillende objecten... dat heeft dus geen nut. Wat ik zei klopte volledig.

In mijn voorbeeld is er maar 1 object en heeft het dus wel nut. Als je synchronized over System.in gaat het wel goed omdat je dan hetzelfde object gebruikt.

Dus, niet... Check mijn code een paar postings terug... Die werkt wel degelijk....

[Verwijderd]

Op vrijdag 21 december 2001 21:08 schreef mbravenboer het volgende:

[..]

Nee, het is dus wel zo! Je maakt een synchronized block (monitor) over twee verschillende objecten... dat heeft dus geen nut. Wat ik zei klopte volledig.

In mijn voorbeeld is er maar 1 object en heeft het dus wel nut. Als je synchronized over System.in gaat het wel goed omdat je dan hetzelfde object gebruikt.

Ik moet nu weg helaas... Maar mocht je hier nog over door willen discussieeren kun je me bereiken op mijn email.. (Staat in m'n profile).

[mbravenboer]

razor_harm: Dus, niet... Check mijn code een paar postings terug... Die werkt wel degelijk....

Ik krijg deze output:

code:

Thread: A is waiting for input. Stop feed with '.'
Thread: B is waiting for input. Stop feed with '.'
.
Thread: A stopped feed.
.
Thread: B stopped feed.

Dit betekent dus dat Thread A en B allebei in de monitor zitten. Het gedrag is niet veranderd ten opzichte van het oorspronkelijke gedrag... Dit komt dus omdat je monitor op twee verschillende objecten werkte: twee andere readers.

Met mijn stukje code krijg ik dit:

code:

Thread: A is waiting for input. Stop feed with '.'
.
Thread: A stopped feed.
Thread: B is waiting for input. Stop feed with '.'
.
Thread: B stopped feed.

Het verschil lijkt me duidelijk...

[Verwijderd]

Op vrijdag 21 december 2001 21:16 schreef mbravenboer het volgende:

[..]

Ik krijg deze output:

code:

Thread: A is waiting for input. Stop feed with '.'
Thread: B is waiting for input. Stop feed with '.'
.
Thread: A stopped feed.
.
Thread: B stopped feed.

Dit betekent dus dat Thread A en B allebei in de monitor zitten. Het gedrag is niet veranderd ten opzichte van het oorspronkelijke gedrag... Dit komt dus omdat je monitor op twee verschillende objecten werkte: twee andere readers.

Met mijn stukje code krijg ik dit:

code:

Thread: A is waiting for input. Stop feed with '.'
.
Thread: A stopped feed.
Thread: B is waiting for input. Stop feed with '.'
.
Thread: B stopped feed.

Het verschil lijkt me duidelijk...

Je hebt wel gelijk natuurlijk.. We bedoelen namelijk hetzelfde... Echter is het wel zo dat het niet komt omdat we het reader object nu als een private attribuut hebben opgenomen i.p.v. telkens een nieuwe instantie (Zie ook mijn code van een paar postings terug, daar doe ik in feite hetzelfde). De fout in mijn eerste code was dat ik maar 1 van de methodes synchroniseerde i.p.v. allebei de stukken die het System.in object gebruiken...

Bedankt in ieder geval !

[mbravenboer]

Ik moest het toch ergens droppen, dus doe het maar ff hier .

Ik zag net JSR-166 langskomen: Concurrency Utils.

"The JSR proposes a set of medium-level utilities that provide
functionality commonly needed in concurrent programs.

Uiteraard wordt deze geleid door Doug Lea .
http://jcp.org/jsr/detail/166.jsp

Je zou het kunnen zien als een voorbereiding voor het opnemen van de library van Doug Lea zelf:
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html

Ik vind dit een uitermate goede ontwikkeling. Het kan absoluut geen kwaad om utils aan te bieden die gebruik maken van de atomaire multi-threading mogelijkheden van Java .