Threads funktionieren nicht

[Jessy12]

Hallo, ich habe vor kurzem angefangen mich in das Thema Threads einzulesen. Nun funktioniert aber etwas nicht so, wie ich es eigentlich dachte verstanden zu haben. In dem unteren Code wird der von lock() und unlock() eingeschlossene Bereich von beiden Threads gleichzeitig ausgeführt .. Müsste nicht der zweite warten, bis der erste fertig ist? Bzw. warum macht er das nicht...

Danke!

package Faeden;

import java.util.concurrent.locks.*;

public class Testen extends Thread {
	TestAusgabe test123;
	
	public Testen(String str) {
		super(str);
		test123 = new TestAusgabe();
	}
	
	@Override public void run() {
		test123.mach();
		
	}
	
	public static void main(String[] args) {
		Testen test1 = new Testen("No1");
		Testen test2 = new Testen("No2");
		test1.start(); test2.start();
	}
}

class TestAusgabe {
	ReadWriteLock readWrite = new ReentrantReadWriteLock();
	Lock readLock = readWrite.readLock();
	Lock writeLock = readWrite.writeLock();
	Lock lock = new ReentrantLock();
	
	public void mach() {
		lock.lock();
		for(int k = 0; k < 10; k++) {
			System.out.println(k + " " + Thread.currentThread());
			try {
				Thread.sleep(100);
			}
			catch(InterruptedException exc) {
				exc.getStackTrace();
			}
		}
		lock.unlock();
	}
}

 

[Cola_Colin]

Du legst den Lock für jeden Thread neu an.

 

[Jessy12]

Stimmt doch gar nicht, es gibt nur ein Objekt vom Typ TestAusgabe und daher auch nur ein ReentrantLock-Objekt ... Bzw. könntest Du mir das genauer erklären?

 

[tfa]

Schau dir Zeile 10 an und überlege, wie oft die abgearbeitet wird.

 

[Jessy12]

Ups ... Da hätte ich einfach mal genauer hinschauen sollen. Trotzdem danke für die schnelle Antwort

 

[Andi_CH]

Stimmt doch gar nicht

Du machst zwei mal

new Testen

und in jedem machst du

new TestAusgabe

und in jedem von denen machst du

new ReentrantReadWriteLock();

By the way - weisst du was ein Debugger ist? Oder wie man sysout einsetzen kann um solche Sachen zu überprüfen?

 

[bygones]

ein hoch auf Work-In-Constructor...

nutz dependency injection fuer sowas

 

[Andi_CH]

ein hoch auf Work-In-Constructor...

nutz dependency injection fuer sowas

Was ist denn das?

Ach noch einfacher ist es, wenn man am Anfang ein Diagramm (z.B. UML) zeichnet. Dann weiss man was man eigentlich will und wer wann was instanziert und initialisiert.

 

[Fu3L]

ein hoch auf Work-In-Constructor...

nutz dependency injection fuer sowas

Was ist denn das?.

Mit Panzern auf Spatzen (oder welche Übertreibung man gerne anbringen möchte in diesem Sprichwort^^)... Man sollte seine Sprache schon erstmal so beherrschen, bevor man sich mit DI auseinandersetzt.
(Allerdings finde ich gut, dass es hier ständig erwähnt wird, weil ich nur so drauf aufmerksam wurde^^ )

Edit: Bezog DI hier auf sowas wie Spring oder Guice

 

[bygones]

Was ist denn das?

Ach noch einfacher ist es, wenn man am Anfang ein Diagramm (z.B. UML) zeichnet. Dann weiss man was man eigentlich will und wer wann was instanziert und initialisiert.

work in constructor ist das was es sagt... es wird arbeit im konstruktor gemacht, ausser zuweisung - nicht gut

Dependency injection ist auch das was es sagt - Abhaengigkeiten werden reingereicht und nicht selbst erstellt

 public Testen(String str, TestAusgabe ausgabe) {
        super(str);
        test123 = ausgabe;
    }

UML Diagramme zu zeichnen sind (meiner ansicht nach) unsinnig und nicht helfend.

 

[Andi_CH]

Bei allem was > "hello world" ist und noch nicht 10 mal implementiert wurde, helfe Diagramme - die meisten Menschen überblicken Abhängigkeiten viel besser, wenn sie grafisch dargestellt sind.

(Bevor du widersprichst, denk mal an die wirren Codehaufen die wir hier zu sehen bekommen )
--
Wie sagte unser Professor für Informatik schon vor diversen Jährchen?

"Wir beginnen heute mit Programmieren - schalten Sie alle bitte ihr Terminal AUS" (ja wir sassen noch vor Terminals )