[JAVA] threads en timers

[Verwijderd]

Ik ben pas weer begonnen met mijn eigen java applicatie en loop nu tegen het volgende probleem op.

Eerst even wat algemene info. Wat de applicatie moet doen is het volgende.

Ik ben bezig met de A.L.I.C.E bot (www.alice.org) dit is een AI persoonlijkheid waar ik wat mee aan het spelen ben. Nu wil ik echter dat deze bot continu gevoed wordt met nieuwe informatie.

Dit gedeelte doe ik dus met de java applicatie. Op dit moment zoekt ie een stuk of 30 sites af naar informatie en dumpt die in een database (dit doet ie om een bepaalde tijd, de ene site 900 sec. een andere weer 450 sec.) Van al de opgehaalde informatie wordt om het kwartier een aiml (xml formaat gebruikt door A.L.I.C.E) file gemaakt die dan rechtstreeks door de bot gebruikt kan worden als informatiebron.

Tot zover allemaal geen problemen en dit werkt ook allemaal. Alle verschillende tijdsintervallen voor het ophalen van info wordt gemanaged mbv timers.

En deze timers zijn het probleem. Ik ging ervan uit (niet de API doorgelezen) dat zodra je een timerobject maakt er niet gelijk een thread voor opgestart zou worden. Dit is wel het geval. Op dit moment is het nog niet zo'n probleem om 30 java threads tegelijk te hebben lopen. Alleen ik ben dit aan het uitbreiden en ik wil dit terugbrengen tot maximaal 10.

Ik wil hiervoor een threadpool gebruiken en de implementatie daarvan is niet het probleem. Het probleem is dat ik geen idee heb hoe ik ervoor kan zorgen dat ik die verschillende threads kan laten starten op een bepaald moment zonder timers te gebruiken. Of op een andere manier zodat niet elke timer een aparte thread nodig heeft.

Even kort samengevat ik heb dit.

Object1 interval 900 sec.
Object2 interval 800 sec.
Object3 interval 650 sec.
..
Objectn interval n sec.

Als ik dit via timers doe krijg ik ook n timerthreads. Is hier een oplossing voor of heeft iemand mischien een idee hoe ik dit anders aan kan pakken.

[marcusk]

Ik zou zeggen: maak één (lage prioriteit) thread waarin je (handmatig) checkt op alle intervallen. 1 timerthread dus voor alle timers.

[Alarmnummer]

Dit moet voor jou toch niet zo`n probleem zijn als je invoer van A.L.I.C.E kan halen uit het afscannen van sites?

Je hoeft trouwens niet een timer object voor een thread te maken. Een timer is een thread die om de x aantal seconden iets voor je doet.

En zo lang die timers niet allemaal naast elkaar lopen te draaien dan is er toch helemaal niets aan de hand?

voor documentatie Timer zie:
http://java.sun.com/j2se/1.4/docs/api/java/util/Timer.html

[mbravenboer]

Als al die timers op een andere interval moeten werken heb je in principe toch echt voor elke timer een thread nodig. Je kunt immers alleen thread laten wachten. Vanuit dat standpunt kan je echter misschien gaan optimaliseren....

Als je nu eens de intervallen merged in een ingewikkelder interval patroon zodat 1 thread de events kan afvuren als er iets moet gebeuren?

Bijvoorbeeld:

Eerst had je dit:

code:

400 event 400 event 400 event 400 event 400 ...
150 event 150 event 150 event 150 event 150 ...

Dit moet in principe door 2 threads gedaan worden, maar kan ook met 1 thread:

code:

150 event 150 event 100 event 50 event 150 event 150 event 50 event ...

Op deze manier hoeft maar 1 thread de events af te vuren...

Je moet alleen even zorgen dat je het ook kan regelen dat op 1 tijdstip meerdere events afgevuurd worden als intervallen precies samenvallen.... (als dat nodig is).

Ik hoop dat ik je goed begrepen heb .

[Verwijderd]

Dit moet voor jou toch niet zo`n probleem zijn als je invoer van A.L.I.C.E kan halen uit het afscannen van sites?

Het zorgt maar voor een klein gedeelte van de output die alice geeft, bijv. als iemand wat wil weten over het laatste nieuws over java oid, bijv een linkje met beschrijving.

Als je nu eens de intervallen merged in een ingewikkelder interval patroon zodat 1 thread de events kan afvuren als er iets moet gebeuren?

Ik zal hier eens naar gaan kijken, is mischien wel mogelijk.


Even nog een klein vraagje over Timers. Is het mogelijk om in 1 Timer meerdere tasks te shedulen? Als ik zo de API doorlees wel. Ik zal dit eens gaan proberen, dan is mischien mijn probleem geen probleem meer.

[Alarmnummer]

Je zou ook de grootste gemeenschapelijke deeler kunnen gebruiken uit je intervallen als timer waarde..

timer1 = 1000 ms
timer2 = 250 ms
timer3 = 100 ms

dan zou je een nieuwe timer kunnen maken die om de 50 ms wordt aangeroepen.

Je moet dan even voor iedere interval het aantal tikken bepalen wat hij nodig heeft.

timer1 = 1000ms/(50ms/tik)=20 tikken
timer2 = 250ms/(50ms/tik)=5 tikken
timer3 = 100ms(50ms/tik)=2 tikken

en dan per basis interval de tikCount 1 ophogen,

en dan

if(tikCount mod 20) = 0 then timer1
if(tikCount mod 5) = 0 then timer2
if(tikCount mod 2)=0 then timer3

[mbravenboer]

Sosume: Even nog een klein vraagje over Timers. Is het mogelijk om in 1 Timer meerdere tasks te shedulen? Als ik zo de API doorlees wel. Ik zal dit eens gaan proberen, dan is mischien mijn probleem geen probleem meer.

Hum Timers zijn niet echt een atomaire multi-threading operatie, het is gewoon een eenvoudige manier om op een bepaalde manier met multi-threading te werken.

Je kunt wel meerdere tasks met 1 timer gebruiken, maar elke task gebruikt een eigen thread volgens mij, dus dat schiet niet zo op.

Als je het efficient wilt doen moet je dus intervallen gaan mergen zoals ik hierboven voordeed (en Alarmnummer later ook nog). Je kunt dan dus wel met 1 thread werken.... Je hebt dan wel eigen implementatie nodig...

[Verwijderd]

Nou na een mislukt 1 timer multiple task expiriment, ga ik toch maar kijken naar de intervallen, eens kijken of ik die niet zo aan kan passen dat de intervallen makkelijk te mergen zijn.

Heb ik iig weer iets te doen. Jullie horen het wel weer als ik weer tegen problemen aanloop.

[mbravenboer]

Misschien is het handig om je design in een aantal lagen op te zetten. Je verdeelt dan mooi je complexiteit .

Maak bijvoorbeeld een timer die z'n volgende wachttijd uit een interval iterator haalt oid... Je kunt dan eerst een degelijke timer maken en daarna gaan stoeien met het samenvoegen van intervallen .

[marcusk]

Ik snap niet echt wat jullie nou moeilijk doen hoor Kan het niet gewoon zo: ?
(sorry voor de lap code )

code:

public class Interval
{
    private Runnable m_action;
    private long m_ival;
    private long m_next;
    
    public Interval(Runnable p_action, long p_ival)
    {
        m_action = p_action;
        m_ival = p_ival;
        m_next = new Date().getTime() + m_ival;
    }
    public Runnable getAction()
    {
        return m_action;
    }   
    public boolean isScheduled()
    {
        long curtime = new Date().getTime();
        
        if (curtime >= m_next)
        {
            m_next = curtime + m_ival; // of m_next + m_ival
            return true;
        }
        else
            return false;
    }
}

public class Scheduler extends Thread
{
    private Vector m_ivals;
    
    public Scheduler()
    {
        m_ivals = new Vector();
    }
    public void addInterval(Interval p_ival)
    {
        m_ivals.add(p_ival);
    }       
    public void run()
    {
        while (true)
            check();
    }
    private void check()
    {
        for (Iterator it = m_ivals.iterator(); it.hasNext(); 
            Interval i = (Interval)it.next())
        {
            if (i.isScheduled())
                new Thread(i.getAction()).start();
        }
    }
}

[mbravenboer]

Das nogal een drukke thread .

Ik denk dat je toch echt met echte sleeps moet werken....

[marcusk]

Op dinsdag 29 januari 2002 21:37 schreef mbravenboer het volgende:
Das nogal een drukke thread .

Oh, ik zou verwachten dat het niet zo veel uit maakt aangezien ie low-priority is

Ik denk dat je toch echt met echte sleeps moet werken....

Maar doen sleeps dan niet iets vergelijkbaars ?

[mbravenboer]

marcusk: Maar doen sleeps dan niet iets vergelijkbaars ?

Nee:

http://java.sun.com/products/jfc/tsc/articles/timer/

In programs written without the benefit of timers, you'll see some rather nasty code for providing delays or periodic task execution. The nastiest algorithm of all is the busy wait loop. This little embarassment attempts to create a delay by keeping the CPU busy:

<knip-code>

The reasons why busy wait loops are a bad idea are legion and obvious, so we won't enumerate them here.

Ik weet trouwens niet zeker of het ook vastgelegd is dat in elke JVM een sleep implementatie ook echt niet busy mag zijn. In de normale gevallen kan je daar echter wel vanuit gaan (hoewel je erg moet oppassen met 'van dingen uitgaan' bij concurrent programming ).

----
Overigens zou je wellicht ook nog wel leuk met een wait-notify mechanisme kunnen werken en een aparte thread die events afvuurt .

[marcusk]

The nastiest algorithm of all is the busy wait loop. This little embarassment attempts to create a delay by keeping the CPU busy:

hmmm...

[Verwijderd]

Om nog maar eens even door te gaan over threads.

Ik heb de volgende code

code:

  public static void main(String[] args)
  {
  try
    {
    Thread.sleep(30000);
    }
  catch (Exception e)
    {
     exceptionhandling.catchException(e);
    }
  }

Als ik hier een jar file van maak en deze dan onder linux draai, zie ik 9 java processen. Is dit normaal?? Ik zou er toch maar 1tje moeten zien?

[mbravenboer]

marcusk: hmmm...

Het waren niet mijn woorden .

Sosume: Is dit normaal?? Ik zou er toch maar 1tje moeten zien?

De JVM zal er ook een aantal in beslag nemen, sowieso voor garbage collection bijvoorbeeld. Wat ze allemaal stuk voor stuk uitvreten weet ik echter ook niet .