Mit Countdown Midnestdauer für Teilaufgabenerledigung erzwingen

[berndoa]

Hallo,
ich habe ein mehr oder weniger gut geschriebenes Programm, in dem mehrere Unteraufgaben erledigt werden.

Für manche der Unteraufgaben will ich einfach dass das Programm (natürlich) die Aufgabe ausführt.
Aber ich will auch von der aufgewendeten zeitdauer her ein wenig Struktur reinbringen.
Daher will ich für eine gegebene Aufgabe hinkriegen dass er die Aufgabe erledigt und aber, sollte weniger Zeit als eine gegebene Zeitspanne vergangen sein, er noch bis dahin wartet.

Wenn ich dem programm also bspw. als Unteraufgabe gebe, es soll die Zahlen 1-1000 in der Konsole drucken.
Und gebe als Zeitspanne 4 Sekunden vor.

Dann will ich dass er die 1000 Zahlen auf der Konsole ausgibt, selbstredend.
Und dann aber , seit Beginn der Aufgabe noch keine 4 Sekunden rum sein, dass er so lange wartet bis eben 4 sekunden rum sind.

Falls er für die eigentliche aufgabe so schon länger als 4 sekunden gebraucht hat, soll er gar nix extra tun.

Damit kann ich sicherstellen dass das pogramm in jedem fall eine Zeit von max{Länge der Aufgabe, 4 sekunden} braucht.
Klar ist das sinnfrei, aber mit etwas gedrehe an der vorgegebenen Zeitspanne kann ich dann bspw. sicherstellen dass er für eine Aufgabe, je nach CPU AUslastung und so,
nicht einmal 1.97 sekunden, dann 3.54, dann 2,31 sekunden braucht.
sondern konstant 4 sekunden (falls ich halt durhc trial and error recht sicher weiß dass er nie länger als 4 sekunden für die aufgabe braucht und 4 sekunden als zeitspanne vorgebe)


Frage ist nun, wie umsetzen?

Habe einige Aufgaben im Skript, mit unterschiedlichen vorzugebenden Zeitdauern.


Mein naives Vorgehen wäre die folgt:
Eine Methode wie folgt definieren:

    public void sleeptilltarget(long startTime, long targetmilliTime){
        long tosleep=1000000*targetmilliTime-(System.nanoTime()-startTime);
        if(tosleep>10000000){//10 milliseconds
            try{
                long millis= (long) (tosleep / 1000000.0);
                Thread.sleep(millis);
            }
            catch(Exception e){}
        }
        return;
    }

Dann im Objekt (Alles passiert in dem eine bestimmten Objekt) ein Attribut Starttime einbauen, das ich bei bedarf anpassen kann.

Wo auch immer eine Aufgabe kommt, dann sowas wie

StartTime=System.nanoTime();
//hier dutzende Zeilen die die Aufgabe erledigen
sleeptilltarget(StartTime,4000);

wenn ich 4 sekunden=4000 millisekunden dauer haben will.

Aber da muss ich halt überall vor einer aufgabe das starttime attribut ändern bzw. für gleichzeitig beobachtete Sachen separate starttime attribute bauen (wenn ich bspw. gleichzeitig die dauer des gesamtprogramms und die von unteraufgaben C7 beobachten will, braucht es ja 2 attribute aka variabeln um die untershciedlichen startzeiten zu tracken)

Hat Jemand eine bessere Idee wie ich das Ganze umsetzen könnte?
Bin noch nicht so wirklich zufrieden damit, obwohl es den Zweck wohl erfüllen sollte.
shcön ist es halt aber nicht wenn die startzeit als attribut gespeichert wird und eben die methode aufgerufen werden muss.

Habe so das gefühl, so eine art countdown müsste man irgendwie intelligenter hinbekommen können :-/


Bevor ich diese idee aufgriff, hatte ich bspw. einfahc einen 20 sekunden sleep hinter jede aufgabe gepackt.
Was natürlich witzlos ist, da wartet dann die meiste zeit das programm "auf schön Wetter" wo es längst weiterarbeiten könnte.Und an anderer stelle habe ich den sleep womöglich zu kurz angesetzt sodass es nicht mehr läuft wie gewohnt.
(Mein programm hängt auch von "äusseren geschehnissen" ab, bspw. klickt mein Programm einen button, nach einer gewissen zeit erscheint dann ein button und ds programm soll die farbe des buttons ablesen. viel variable zeitdauern drin, die ich aber effizienztechnisch halbwegs eingrenzen will)

 

[LimDul]

Das kann man mit Lambdas schön lösen:

package de.limdul.javaforum;

import java.time.LocalDateTime;
import java.util.function.Supplier;

public class RunAndWait {

    public static <T> T runAndWait(Supplier<T> methodToRun, int secondsToWait, Class<T> resultClass) {
        long currentTimeMillis = System.currentTimeMillis();
        T result = methodToRun.get();
        long duration = System.currentTimeMillis() - currentTimeMillis;
        long waitTime = secondsToWait * 1000 - duration;
        try {
            Thread.sleep(waitTime);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return result;
    }

    public static void runAndWait(Runnable methodToRun, int secondsToWait) {
        long currentTimeMillis = System.currentTimeMillis();
        methodToRun.run();
        long duration = System.currentTimeMillis() - currentTimeMillis;
        long waitTime = secondsToWait * 1000 - duration;
        try {
            Thread.sleep(waitTime);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) {
        System.out.println("Start: " + LocalDateTime.now());
        int result = runAndWait(() -> calculateFibonacci(10), 5, Integer.class);
        System.out.println(result);
        System.out.println("End: " + LocalDateTime.now());
    }

    public static int calculateFibonacci(int n) {
        if (n <= 0) {
            return 0;
        } else if (n == 1) {
            return n;
        } else {
            return calculateFibonacci(n - 1) + calculateFibonacci(n - 2);
        }
    }

}

Zwei Hilfsmethoden, die das übernehmen, eine die Methoden aufrufen kann, die einen Wert zurückgeben, eine die für void-Methoden einfacher ist.

Beispielausgabe des Programms:

Start: 2022-05-13T21:14:33.322878600
55
End: 2022-05-13T21:14:38.334582300

 

[berndoa]

Das kann man mit Lambdas schön lösen:

package de.limdul.javaforum;

import java.time.LocalDateTime;
import java.util.function.Supplier;

public class RunAndWait {

    public static <T> T runAndWait(Supplier<T> methodToRun, int secondsToWait, Class<T> resultClass) {
        long currentTimeMillis = System.currentTimeMillis();
        T result = methodToRun.get();
        long duration = System.currentTimeMillis() - currentTimeMillis;
        long waitTime = secondsToWait * 1000 - duration;
        try {
            Thread.sleep(waitTime);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return result;
    }

    public static void runAndWait(Runnable methodToRun, int secondsToWait) {
        long currentTimeMillis = System.currentTimeMillis();
        methodToRun.run();
        long duration = System.currentTimeMillis() - currentTimeMillis;
        long waitTime = secondsToWait * 1000 - duration;
        try {
            Thread.sleep(waitTime);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) {
        System.out.println("Start: " + LocalDateTime.now());
        int result = runAndWait(() -> calculateFibonacci(10), 5, Integer.class);
        System.out.println(result);
        System.out.println("End: " + LocalDateTime.now());
    }

    public static int calculateFibonacci(int n) {
        if (n <= 0) {
            return 0;
        } else if (n == 1) {
            return n;
        } else {
            return calculateFibonacci(n - 1) + calculateFibonacci(n - 2);
        }
    }

}

Zwei Hilfsmethoden, die das übernehmen, eine die Methoden aufrufen kann, die einen Wert zurückgeben, eine die für void-Methoden einfacher ist.

Beispielausgabe des Programms:

Puh, also von Lambdas habe ich jetzt wirklich gar keine Ahnung.
Ich kenn das bloss von formalen Sprachen, Grammatiken und so, hat aber vermutlich hiermit gar nix zu tun :-D

 

[mihe7]

Puh, also von Lambdas habe ich jetzt wirklich gar keine Ahnung.

In dem Code taucht auch nur ein Lambda-Ausdruck auf, nämlich in Zeile 35:

int result = runAndWait(() -> calculateFibonacci(10), 5, Integer.class);

Wie Du aus den Parametern (allein schon an der Anzahl) ableiten kannst, wird hier die Methode

public static <T> T runAndWait(Supplier<T> methodToRun, int secondsToWait, Class<T> resultClass)

aufgerufen. Als Argument für den Parameter methodToRun wird also der Lambda-Ausdruck () -> calculateFibonacci(10) verwendet.

Ignorieren wir mal den Lamda-Ausdruck. Die Methode erwartet für methodToRun ein Objekt mit Supplier<T>-Interface. Der Typ T ergibt sich aus dem dritten Parameter resultClass.

Im Code, Zeile 35 (s. o.), wurde Integer.class übergeben, so dass im Aufruf ein Objekt mit Supplier<Integer>-Implementierung übergeben werden muss.

Und das kannst Du natürlich genauso wie ein Runnable-Interface z. B. mit einer anonymen inneren Klasse erzeugen:

int result = runAndWait(new Supplier<Integer>() {
        @Override
        public Integer get() {
            return calculateFibonacci(10);
        }
    }, 5, Integer.class);

Sprich: Du kannst den Lambda-Ausdruck () -> calculateFibonacci(10) hier einfach als Kurzschreibweise für

new Supplier<Integer>() {
        @Override
        public Integer get() {
            return calculateFibonacci(10);
        }
}

betrachten.

 

[berndoa]

Das muss ich mir noch ein paar mal durchlesen, bis ich das kapiert habe.
Aber mal so konzeptuell gesprochen hast du im Prinzip das, was ich machen würde (Startzeit merken, kram machen, bisherige dauer berechnen, restzeit warten) in eine eigene runAndWait Methode ausgelagert, die du halt aufrufst.
Und rgendwie noch übergibst, was genau an der "rakm machen" Stelle an methode ausgeführt wird

 

[berndoa]

In dem Code taucht auch nur ein Lambda-Ausdruck auf, nämlich in Zeile 35:

int result = runAndWait(() -> calculateFibonacci(10), 5, Integer.class);

Wie Du aus den Parametern (allein schon an der Anzahl) ableiten kannst, wird hier die Methode

public static <T> T runAndWait(Supplier<T> methodToRun, int secondsToWait, Class<T> resultClass)

aufgerufen. Als Argument für den Parameter methodToRun wird also der Lambda-Ausdruck () -> calculateFibonacci(10) verwendet.

Ignorieren wir mal den Lamda-Ausdruck. Die Methode erwartet für methodToRun ein Objekt mit Supplier<T>-Interface. Der Typ T ergibt sich aus dem dritten Parameter resultClass.

Im Code, Zeile 35 (s. o.), wurde Integer.class übergeben, so dass im Aufruf ein Objekt mit Supplier<Integer>-Implementierung übergeben werden muss.

Und das kannst Du natürlich genauso wie ein Runnable-Interface z. B. mit einer anonymen inneren Klasse erzeugen:

int result = runAndWait(new Supplier<Integer>() {
        @Override
        public Integer get() {
            return calculateFibonacci(10);
        }
    }, 5, Integer.class);

Sprich: Du kannst den Lambda-Ausdruck () -> calculateFibonacci(10) hier einfach als Kurzschreibweise für

new Supplier<Integer>() {
        @Override
        public Integer get() {
            return calculateFibonacci(10);
        }
}

betrachten.

Ich sollte mich echt mal näher mit Java beschäftigen.
Ich habe bspw. keine Ahnung was ein Runnable, Supplier, etc. ist.
Geschweigedenn diese Konstruktionen wie Methodenname.run().

Ich kenne nur die Nooblevelsachen wie
Klassenname.methodenname() und so.

Das hier scheinen mir mehr so "Meta" Sachen zu sein :-D

Aber cool zu wissen dass man einer Methode gewissermassen eine andere Methode als Argument übergeben kann (eben so ein Runnable Teil).

Dadurch kann man ja variieren welche Methode die runAndWait Methode genau ausführen soll, statt es hardcoden zu müssen.

 

[mihe7]

Ich habe bspw. keine Ahnung was ein Runnable, Supplier, etc. ist.

Runnable und Supplier sind einfach zwei Interfaces, die jeweils nur eine Methode enthalten.

Das Runnable-Interface spezifiziert die Methode void run(), das Supplier-Interface die Methode T get().

Daher kannst Du natürlich, wenn Du ein Runnable ("ein Runnable" = Kurz für "Objekt mit implementierter Runnable-Schnittstelle") erhältst, die run()-Methode aufrufen. Analog, wenn Du einen Supplier bekommst, die get()-Methode.

 

[berndoa]

Runnable und Supplier sind einfach zwei Interfaces, die jeweils nur eine Methode enthalten.

Das Runnable-Interface spezifiziert die Methode void run(), das Supplier-Interface die Methode T get().

Daher kannst Du natürlich, wenn Du ein Runnable ("ein Runnable" = Kurz für "Objekt mit implementierter Runnable-Schnittstelle") erhältst, die run()-Methode aufrufen. Analog, wenn Du einen Supplier bekommst, die get()-Methode.

Das ist klar, nur was nun Runnablename.run() bzw. SUppliername.get() genau tut, ist die Frage.

Ein interface per se gibt ja noch gar nichts vor, was es tut, das kommt ja sozusagen erst in der Implementierung davon.


Ich sehe dass der Code so Sinn macht im Sinne von (überall wurde das an die Methode übergeben was erwartett wurde).
Aber was es nun genau heißt, wenn ein RUnnable gerunt wird, naja....

Edit:
Bspw. bei

public static <T> T runAndWait(Supplier<T> methodToRun, int secondsToWait, Class<T> resultClass)

sehe ich weder in der Signatur noch im Methodenrumpf irgendwas, was mir (oder dem Computer) sagt
dass resultclass und methodtorun irgendwas miteinander zu tun haben.
Ich meine resultclass wird zwar als argument übergeben aber sprichwörtlich kommt es nirgends in der Methode vor, zumindest nicht offensichtlich.

Da fehlt mir wohl einfah Bskgroundknowledge wie java seine runnables, Suppliers, Classes(?) und so händelt. Denn eine stinknormales Interface ist das vermutlich nicht, da läuft eingie Magie im hintergrund

 

[mihe7]

Ich sehe dass der Code so Sinn macht im Sinne von (überall wurde das an die Methode übergeben was erwartett wurde).
Aber was es nun genau heißt, wenn ein RUnnable gerunt wird, naja....

Das sind ganz normale Methodenaufrufe - und was die Methoden machen, hängt in erster Linie von der Spezifikation des Interfaces ab (die in Java allerdings zum großen Teil nicht formal sondern per Dokumentation erfolgt): https://docs.oracle.com/javase/8/docs/api/java/lang/Runnable.html,

Supplier (Java Platform SE 8 )

docs.oracle.com

Die Spezifikation schränkt die möglichen Implementierungen ein. Bei diesen Interfaces ist sie - absichtlich - recht allgemein gehalten. Beim List-Interface ist das dagegen sehr viel genauer.

Da fehlt mir wohl einfah Bskgroundknowledge wie java seine runnables, Suppliers, Classes(?) und so händelt. Denn eine stinknormales Interface ist das vermutlich nicht, da läuft eingie Magie im hintergrund

Doch, das sind stinknormale Interfaces. Der Code dürfte (EDIT: ungefähr) so aussehen:

public interface Runnable {
    void run();
}

public interface Supplier<T> {
    T get();
}

Das wars.