scheduleAtFixedRate scheduleWithFixedDelay Unterschied?

[Jessy12]

Ja, wie der Titel schon sagt: Was ist denn nun der Unterschied zwischen diesen beiden Methoden? Für micht sehen die völlig identisch aus ...

Danke

 

[Jessy12]

Da der Thread schonmal offen ist, habe ich gleich noch eine weitere Frage, auch wenn sie nicht wirklich was mit dem Titel zu tun hat. Aber sont müsste ich einen neuen Thread aufmachen ...

Beim Experimentieren mit Threads auf eine Exception gestoßen, die ich mir nicht erklären kann:

package testflaeche;

import java.util.*;
import java.util.concurrent.*;
import java.util.concurrent.locks.*;

public class Test7 extends Thread {
	public static ReentrantLock lock = new ReentrantLock();
	
	@Override
	public void run() {
		lock.tryLock();
			System.out.println("TEST");
			try {
				Thread.sleep(5000);
			}
			catch(InterruptedException exc) {
				exc.printStackTrace();
			}
		if(lock.isLocked()) lock.unlock();
		System.out.println("TEST3");
	}

	public static void main(String[] args) {
		ExecutorService exec = Executors.newCachedThreadPool();
		Test7 t1 = new Test7();
		Test7 t2 = new Test7();
		exec.execute(t1);
		exec.execute(t2);
	}
}

tryLock() hat ja nur den Sinn, dass wenn der lock() schon drinne ist, tryLock() trotzdem in den kritischen Bereich eintritt und den Zusatz des Rückgabewerts, ob beim Eintritt der Lock gesetzt war oder nicht. Wenn er nicht gesetzt war, dann setzt in tryLock(), also verhält sich die Methode in dem Fall wie ein normaler lock().
Aber warum bekomme ich bei unlock() eine IllegalMonitorStateException? Woher rührt diese?

Danke im Voraus

 

[Noctarius]

1) Javadoc lesen, steht da ganz klar drin der Unterschied: ScheduledExecutorService (Java Platform SE 6)

2) unlock() sollte IMMER in einem finally-Block aufgerufen werden.

Stell dir mal vor, es fliegt eine andere Exception als InterrruptedException, dann wird dein Lock nie mehr frei gegeben!

Die IllegalMonitorStateException sehe ich nicht, wo ist denn der Stacktrace?

 

[Jessy12]

Ich habe mir die API davor auch schon angeschaut und ich sehe bei der Methodenbeschreibung keinen wirklichen Unterschied. Die Rückgabe ist gleich und die Parameter haben genau die gleiche Aufgabe ...

Der Fehler kommt beim Aufruf von unlock() und es liegt irgendwie an dem tryLock() ... Ich glaube die IllegalMonitorStateException kommt immer, wenn unlock() aufgerufen wird, obwohl kein lock() vorherrscht. Aber ich frage doch vorher ab, ob der lock() da ist

 

[Jessy12]

Ok, das Problem zwei lässt sich lösen, wenn ich isLocked() mit isHeldByCurrentThread() austausche. Allerdings ist mir hier der Unterschied auch nicht ganz klar. in der API steht, dass isLockes() prüft, ob irgendein Thread den Lockt hält und bei isHeldByCurrentThread() eben ob der gerade laufende Thread den Lock hält. Den Lock/Monitor hält doch immer das Objekt auf dem ich die lock() Methode aufrufe ... Dann ergeben die Methoden aber in meinen Augen keinen Sinn. Entweder das ReentrantLock hat den Monitor oder eben nicht, das hat doch nichts mit irgendeinem/dem aktuellen Thread zu tun ... Ich kenne mich mit Threads noch nicht so gut aus und es wäre toll, wenn mir jemand erklären könnte, was da mit "current Thread" und "any Thread" genau gemeint ist

 

[Noctarius]

Ok dann kopiere ich dir den Text der 2 Methoden jetzt noch und dann vergleichen wir mal was da genau steht:

scheduleAtFixedRate:

Creates and executes a periodic action that becomes enabled first after the given initial delay, and subsequently with the given period; that is executions will commence after initialDelay then initialDelay+period, then initialDelay + 2 * period, and so on. If any execution of the task encounters an exception, subsequent executions are suppressed. Otherwise, the task will only terminate via cancellation or termination of the executor. If any execution of this task takes longer than its period, then subsequent executions may start late, but will not concurrently execute.

scheduleWithFixedDelay:

Creates and executes a periodic action that becomes enabled first after the given initial delay, and subsequently with the given delay between the termination of one execution and the commencement of the next. If any execution of the task encounters an exception, subsequent executions are suppressed. Otherwise, the task will only terminate via cancellation or termination of the executor.

Jetzt frage ich dich, was ist der Unterschied? Also in meinen Augen steht er ganz klar da!

 

[Jessy12]

scheduleAtFixedRate() lässt anscheinen nicht zu, dass sich zwei Aufrufe überschneiden bzw. verlängert gegebenenfalls die Periode, wenn der Thread nicht innerhalb der Periode zuendegeführt werden konnte. scheduleWithFixedDelay() hingegen lässt auch zu, dass zwei Aufrufe parallel nebeneinander existieren können, falls die Periode zu kurz ist. Sehe ich das richtig?

Wenn ich dieses Szenario aber nachstelle, dann verhalten sich beide Methoden gleich. Im folgenden Code kommt es nicht zur Überschneidung zweier Aufrufe:

package testflaeche;

import java.util.concurrent.*;
import java.util.concurrent.locks.*;

public class Test8 implements Runnable {
	@Override public void run() {
		try{
			System.out.println("start");
			Thread.sleep(10000);
			System.out.println("ende");
		}
		catch(InterruptedException exc) {
			System.out.println("exc");
		}
	}
	
	public static void main(String[] args) {
		ScheduledExecutorService serv = Executors.newSingleThreadScheduledExecutor();
		serv.scheduleWithFixedDelay(new Test8(), 0, 1, TimeUnit.SECONDS);
	}
}

 

[Noctarius]

Tatsächlich sind in der Standardimplementierung beide Versionen nahezu identisch, so dass kein Unterschied auffällt. Trotzdem darfst du dich nur bei atFixedRate darauf verlassen, dass es so ist. Das macht der Name auch klar. Fixe Rate ist definitiv die Verzögerung zwischen 2 Ausführungen, Fixes Delay ist die Verzögerung zwischen 2 Starts.

 

[r.w.]

Tatsächlich sind in der Standardimplementierung beide Versionen nahezu identisch, so dass kein Unterschied auffällt. Trotzdem darfst du dich nur bei atFixedRate darauf verlassen, dass es so ist. Das macht der Name auch klar. Fixe Rate ist definitiv die Verzögerung zwischen 2 Ausführungen, Fixes Delay ist die Verzögerung zwischen 2 Starts.

Ich würde daraus eher schließen, dass bei scheduleAtFixedRate der Zeitraum von Start zu Start und bei scheduleWithFixedDelay der Zeitraum zwischen Beendigung der Aufgabe und Start der nächsten gemeint ist.

Oder liege ich da falsch?

 

[Noctarius]

Lies doch das Javadoc Ich habe es sogar extra kopiert *g*

 

[r.w.]

Lies doch das Javadoc Ich habe es sogar extra kopiert *g*

Genau das hab ich ja getan. ;-)

scheduleAtFixedRate:
...will commence after initialDelay then initialDelay+period, then initialDelay + 2 * period, and so on...

scheduleWithFixedDelay:
...given delay between the termination of one execution and the commencement of the next....

 

[Noctarius]

Dann würden ja doch beide Methoden das Selbe machen.

 

[r.w.]

Dann würden ja doch beide Methoden das Selbe machen.

Ich denke, eben nicht.

Bei scheduleAtFixedRate wird nach dem Start des ersten Aufrufs plus einem fixen Zeitraum der nächste Aufruf gestartet.

Bei scheduleWithFixedDelay wird nach dem Start des Aufrufs gewartet, bis die Aufgabe erledigt ist, und ab da noch einmal der übergebene Zeitraum.

Das heisst, wenn man wirklich fixe Frame-Raten erzielen möchte, hilft nur scheduleAtFixedRate.
Da scheduleWithFixedDelay immer von der Dauer der Aufgabe beeinflusst wird.

Womit ich ja eigentlich Deiner ursprünglichen Aussage zustimme, außer diesem Teil...

...Fixe Rate ist definitiv die Verzögerung zwischen 2 Ausführungen, Fixes Delay ist die Verzögerung zwischen 2 Starts...

Da lese ich keinen Unterschied zwischen Ausführungen und Starts. ;-)

 

[Noctarius]

Ok also es gibt einen Unterschied. Zwar warten beide Versionen bis der vorherige Task fertig ist, atFixedRate fängt aber sofort mit dem nächsten an, falls die Wartezeit bis dahin schon abgelaufen ist während withFixedDelay dann anfängt die Verzögerung zu messen. Mea culpa:

import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;

public class Schedule implements Runnable {
	private static long timer1 = System.currentTimeMillis();
	private static long timer2 = System.currentTimeMillis();

	private final boolean fixedRate;

	private Schedule(final boolean fixedRate) {
		this.fixedRate = fixedRate;
	}

	@Override
	public void run() {
		try {
			System.out.println("start - " + getTypeDescription() + " - "
					+ getMS());

			Thread.sleep(10000);
			System.out.println("ende - " + getTypeDescription());

			if (fixedRate) {
				timer2 = System.currentTimeMillis();
			} else {
				timer1 = System.currentTimeMillis();
			}

		} catch (final InterruptedException exc) {
			System.out.println("exc");
		}
	}

	private String getTypeDescription() {
		return fixedRate ? "scheduleAtFixedRate" : "scheduleWithFixedDelay";
	}

	private long getMS() {
		return System.currentTimeMillis() - (fixedRate ? timer2 : timer1);
	}

	public static void main(final String[] args) {
		final ScheduledExecutorService executor = Executors
				.newScheduledThreadPool(10);

		executor.scheduleWithFixedDelay(new Schedule(false), 0, 1,
				TimeUnit.SECONDS);

		executor.scheduleAtFixedRate(new Schedule(true), 0, 1, TimeUnit.SECONDS);
	}
}

start - scheduleWithFixedDelay - 3
start - scheduleAtFixedRate - 3
ende - scheduleWithFixedDelay
ende - scheduleAtFixedRate
start - scheduleAtFixedRate - 0
start - scheduleWithFixedDelay - 1001
ende - scheduleAtFixedRate
start - scheduleAtFixedRate - 0
ende - scheduleWithFixedDelay
start - scheduleWithFixedDelay - 1001
ende - scheduleAtFixedRate
start - scheduleAtFixedRate - 0

PS: @ TO: newSingleThreadedExecutor kann definitiv keine 2 Tasks gleichzeitig ausführen (fällt mir gerade so auf )

 

[Noctarius]

Ich denke, eben nicht. Das heisst, wenn man wirklich fixe Frame-Raten erzielen möchte, hilft nur scheduleAtFixedRate.

Scheinbar ist das mit der Implementierung nicht möglich.

 

[r.w.]

Scheinbar ist das mit der Implementierung nicht möglich.

Nur dann, wenn man sicher stellt, dass die Frame-Rate so gering ist, dass die
Ausführung auf jeden Fall im übergebenen Zeitraum erledigt werden kann.

Ich wüsste aber auch nicht, wie man das Problem überhaupt lösen könnte.
Parallel geht ja nicht, wie Du schreibst.

 

[Noctarius]

Doch parallel geht schon, mit einem ThreadPoolExecutor, aber nicht mit dem SingleThreaded wie vom TO genutzt.

Es gibt abgesehen von Framerates (die ich niemals so implementieren würde, dafür gibt es den Mainloop), aber andere Dinge die durchaus parallel mit Verzögerung abgearbeitet werden könnten, z.B. Aufräumarbeiten.

 

[r.w.]

Doch parallel geht schon, mit einem ThreadPoolExecutor, aber nicht mit dem SingleThreaded wie vom TO genutzt.

Ach so, da hab ich Deine Aussage falsch interpretiert.

...Framerates (die ich niemals so implementieren würde, dafür gibt es den Mainloop),

Dazu wage ich zur Zeit keine Aussage, da ich mich, abgesehen von kleineren Animationen,
noch nicht allzu intensiv damit beschäftigt hab. Timing ist aber insgesamt schon sehr interessant.