Abtasten mit einem Thread

[Generic1]

Hallo,

ich habe jetzt einen Thread der mit dem größten gemeinsames Vielfachen von ein Paar werten ausgeführt wird, z.B. ist der ggt 2000ms wenn meine Zeiten für die Threads z.B.: 2000ms, 4000ms und 8000ms sind,

nun wird sendMessages ausgeführt und wenn z.B. sendMessages das erste mal ausgeführt wird dann ist 2000ms = 2000ms und es betrifft message1, wenn sendMessage das 2. mal ausgeführt wird, sind 4000ms vergangen und es ist message2 betroffen usw. nach message3 wird wieder von vorne angefangen,

Jetzt meine Frage: wie kann ich das am Besten realisieren, Zeit messen ist ja so eine Sache die nicht so genau ist, und ich müsste diese ja immer wieder auf 0ms setzen,

Hat da jemand eine Idee?

timerTask.scheduleAtFixedRate(this, 0, gcd);  // gcd ist z.B. 2000ms, wie oben erklärt
        
@Override
public void run() {
      serverMessageArray.sendMessages(/* so hab ichs mal zum testen gemacht: Math.abs(new Random().nextInt()%4)*/);
      }

public void sendMessages(int messageIndex) {
        Message message = messages[messageIndex];   // in "messages" sind die message mit 2000, 4000 und 8000 drinnen
        }

 

[Marco13]

Das klingt ein bißchen verworren und kompliziert.... aber ... was spricht dagegen, einfach bei jedem Aufruf von sendMessages den messageIndex um 1 zu erhöhen (und eben bei jedem Zugriff oder regelmäßig
messageIndex %= numberOfMessages;
auszuführen)?

 

[Generic1]

Das klingt ein bißchen verworren und kompliziert.... aber ... was spricht dagegen, einfach bei jedem Aufruf von sendMessages den messageIndex um 1 zu erhöhen (und eben bei jedem Zugriff oder regelmäßig
messageIndex %= numberOfMessages;
auszuführen)?

Ja so hab ichs jetzt ungefähr gelöst, Meine send- Methode schaut jetzt so aus, weiß nicht, ob man da noch was verbessern kann:

public void sendMessages(int threadCycleTime) {
        for(int i = 0; i < messages.length; i++) {
            if (messages[i].getCycleTime() == threadCycleTime * cycleCounter) {
                sendCounter++;
                Message message = messages[i];
                System.out.println(message.getServerInterface() + ", " + message.getProtocol()[0] + ", " + message.getCycleTime());
                break;
                }
            }
        cycleCounter += 1;
        if (sendCounter == messages.length) {
            cycleCounter = 1;
            sendCounter = 0;
            }
        }

 

[FArt]

Das klingt nach einer Optimierung für das Problem: spare Threads bei einem Scheduler, der Aktionen in bestimmten Abständen auszuführen hat wobei ein Thread alle Aktionen übernehmen soll, die im Abstand t oder Vielfachen von t auszuführen sind.

Wenn das so ist: das ist eine unnötige und unpraktische Optimierung. Nimm dann einfach den ScheduledExecutorService aus dem java.util.concurrent Package und verpasse diesem einen Threadpool...

 

[Generic1]

Das klingt nach einer Optimierung für das Problem: spare Threads bei einem Scheduler, der Aktionen in bestimmten Abständen auszuführen hat wobei ein Thread alle Aktionen übernehmen soll, die im Abstand t oder Vielfachen von t auszuführen sind.

Wenn das so ist: das ist eine unnötige und unpraktische Optimierung. Nimm dann einfach den ScheduledExecutorService aus dem java.util.concurrent Package und verpasse diesem einen Threadpool...

Das kann man so zusammenfassen, ich find meine Lösung durchaus praktisch, ich brauche mich nur um den einen Threas kümmern, vor allem, da ich nicht weiß wieviele "Messages" es gibt, es kann nur eine sein, es können aber auch 20 sein und deshalb habe ich diese Lösung gewählt, da sie einfach nachvollziehbar und einfach zu durchschauen ist,

Das einzige was mir ein bisschen Sorgen macht ist, ob es nicht schneller/resourcenschonender wäre, mehrere Thread zu verwenden,

 

[FArt]

Warum ist das nicht so dolle?

1. (relativ) Kompiliziert.
2. Wenn eine Aktion relativ lange für die Ausführung benötigt, "verhungert" die nächste. Nachfolgende Läufe werden auch verschoben

Besser:

Mache ein sauberes Design. Code der einfach aussieht ist guter Code, leicht zu warten, leicht zu erweitern, birgt weniger Fehlerquellen und ist somit leichter auf Qualität zu sichern.
Um Optimierung kümmert man sich bei Bedarf.

Überdenke noch mal meinen Vorschlag mit dem SchedulerExecutorService... der bietet dir für deine Aufgabe noch mehr Voreile...

 

[Generic1]

ich werd beide Lösungen mal ausprogrammieren und mir dann das Ganze mal auschauen, testen und vergleichen, mal schauen was dabei rauskommt,
Bei diesem Programmabschnitt zahlt sich das aus, es geht schließlich und die Kommunikation, und das ist der Hauptbestandteil meines Programms, alles weitere setzt auf diesen Daten auf und daher ist mir die Communication so wichtig,
herzlichen Dank für die Vorschäge,

 

[Generic1]

Hab mir mal ein Programm zusammengebastelt,
ist das mit dem Scheduler ungefähr so gemeint, oder hab ich das falsch verstanden,

package scheduledexecutorservice;

import static java.util.concurrent.TimeUnit.*;
import java.util.concurrent.*;
 
public class MyScheduledExecutorService
{       
    private final ScheduledExecutorService scheduler;
    private int delay;
    private int millisec;
    private String text;
    
    public MyScheduledExecutorService(int corePoolSize, int delay,int millisec, String text) {
        scheduler = Executors.newScheduledThreadPool(corePoolSize);
        this.delay = delay;
        this.millisec = millisec;
        this.text = text;
        }
 
    // start the thread
    public void beepForAnHour() {
        final Runnable beeper = new Runnable() { 
            @Override
            public void run() {
                System.out.println(text);
                }
            };
        final ScheduledFuture<?> beeperHandle = scheduler.scheduleAtFixedRate(beeper, delay, millisec, MILLISECONDS); 
        }
 
    // start the programm 
    public static void main(String args[]) {
        MyScheduledExecutorService mses1 = new MyScheduledExecutorService(3, 1000, 3000, "Test1");
        MyScheduledExecutorService mses2 = new MyScheduledExecutorService(3, 1000, 3000, "Test2");
        //..
        mses1.beepForAnHour();
        mses2.beepForAnHour();
        }
}

 

[FArt]

Wenn es sich so verhält, wie du erwartest, dann ist es auch richtig.