[java] probleem met timing bij thread

[twilightschild]

Ik ben bezig een java programmatje te schrijven voor het gebruiken van de paralelle poort voor elektro doeleinden.
1 ding dat ik wilde doen, was een instelbaar pulsbreedte signaal op een pin van de poort te zetten. Ik heb dit programma eerst "normaal" gemaakt, maar toen vrat het programma al mn cpu tijd op. Ik hoorde van een vriend dat ik het dan met thgreads moest gaan proberen (ik studeer zelf electro en weet met een half jaartje java dus niet zo gek veel van de taal).
Ik heb nu het programma gemaakt met threads, maar ik kan de timing maar niet kloppend krijgen.
Het sleep commando dat ik gebruik kan volgens de api in mS en nS ingesteld worden.
Nu is het zo dat als ik de thread 1 mS geef, deze 2mS gebruikt. Bij 2 mS en hoger klopt alles wel gewoon.
De nano seconden werken al helemaal vreemd. Vanaf 500000 (1/2 mS) wordt als 1mS geteld en daaronder als niets.
Ik kan mn thread dus niet korter dan 2mS laten slapen terwijl ik dat wel nodig heb en het lijkt me ook dat het moet kunnen.
Ik hoop dat iemand me kan vertellen wat ik verkeerd doe.

code:

import java.awt.*;
import java.awt.event.*;
import java.util.*;
import java.io.*;
import hva.PortIO;

class MainDelay
{
  public static void main (String [] arg)
  {
    Writer w1 = new Writer(1,0,1); 
    w1.activity.start();
    Delay.delay(10000,0);   
    w1.activity.interrupt();
    PortIO.outPort(0x378,0);

  }
}

class Writer implements Runnable
{
    public Thread activity = new Thread(this);
    private String text;
    int a;
    int b;
    int c;
    int d;
    int interval2;
    private long interval;


    public Writer(long time, int time2, int a)
    {
        interval = time;
        interval2 = time2;
        this.a = a;

    }


    public void run()
    {
        while(Delay.delay(interval,interval2))
        {
            if(a <= 1)
            {
                PortIO.outPort(0x378,1);
                a++;
            }
            else
            {
            PortIO.outPort(0x378,0);
            a--;
            }

        }


    }
}
class Delay extends Thread
{
    public static boolean delay(long millis, int nanos)
    {
        if(interrupted())
        return false;
        try
        {
            sleep(millis, nanos);
        }
        catch(InterruptedException e)
        {
            return false;
        }
        catch(IllegalArgumentException iae)
        {
        }
        return true;
    }

}

Dit programma zou in princiepe een pulssignaal van 1mS laag en 1mS hoog moeten geven, het is dus 2mS laag en 2mS hoog

[Alarmnummer]

Je code is echt een zootje:
-Waarom maak jij die thread aan in die Writer en dan maak je dat veld ook nog eens publiek. Ik zou dat als volgt oplossen door dit te schrijven in je main:

Thread writerThread = new Thread(new Writer(...));
writerThread.start();

-Gebruik verder niet van die ongelovelijke bagger namen zoals a,b,c,d,e. Geef het een naam zodat je kunt zien wat het is.

-velden van classes mogen in principe niet 'friendly (dus zonder accessmodifier) of public zijn. Het beste kun je overal private voor zetten zodat niemand van buiten af bij de velden kan komen.

-jij maakt een Delay thread aan waarvan de enigste functie die delay functie is. Ik denk dat jij anders niet bij die sleep functie kan komen. Static velden en functies kun je aanroepen door de naam van de class ervoor te zetten. Dus Thread.sleep(...)

-exceptions afvangen en er niets met doen, is not done. Zelfs als dit de bedoeling is dan moet je er commentaar bij zetten dat er niets aan de hand is.

Om antwoord te geven op je vraag. Ik ben niet thuis in zulke lage timings bij die thread dus ik weet niet wat de oorzaak ervan is. Ik zit verder even te kijken naar een Timer library en ik dacht dat de concurrency library van doug lea dat wel in zich had zitten, maar ik zie het ff niet staan.

[F_J_K]

SA --> Programming & Webscripting

[Infinitive]

Het aantal miliseconden dat je aangeeft dat je thread moet slapen is een richtlijn. Er wordt minstens die hoeveelheid tijd geslapen, misschien meer. Dit is onder andere afhankelijk van het aantal threadjes dat processortijd willen hebben. Hoewel met een beetje processor in die milliseconde best wel een hele bak instructies uitgevoerd kunnen worden, dus dat lijkt me niet echt een minimum?

[ACM]

Wellicht dat je voor zulke korte timings es naar Real Time Java moet kijken?
O.a. de PeriodicTimer lijkt me nuttig voor je.

Maar hoe goed dat allemaal op een non-realtime platform (windows/linux) werkt durf ik niet te zeggen
Java kent overigens zelf ook wel een Timer maar die kan niet kleiner dan 1 ms, wellicht dat ie het wel netter doet dan de Thread.sleep-methode. De ClockDaemon van Doug Lea komt ook niet verder dan dat.

Je loopt natuurlijk ook nog een kans dat je poort gewoon niet sneller kan?

[ Voor 7% gewijzigd door ACM op 18-04-2004 13:57 ]

[Creepy]

ACM schreef op 18 april 2004 @ 13:55:
Wellicht dat je voor zulke korte timings es naar Real Time Java moet kijken?
O.a. de PeriodicTimer lijkt me nuttig voor je.

Je loopt natuurlijk ook nog een kans dat je poort gewoon niet sneller kan?

De poort is het probleem niet. Pre-emptive multitasking OS'en (o.a. Windows en Linux) wel.

De manier die je had en 100% cpu vreet is de beste oplossing die je hebt. En zelfs dat is af en toe niet genoeg als er meerdere CPU vretende processen zijn.

Een sleep geeft de CPU tijd af zodat een ander proces of thread zijn werk kan doen. Afhankelijk van het totaal aantal processen en threads kan het enige tijd duren voordat jou thread weer cpu tijd krijgt. Deze tijd is over het algemeen meer dan 1 ms (is OS afhankelijk). Een kortere sleep heeft dus ook totaal geen nut.

[twilightschild]

Ehm over hoe erg mn code een zooi is, tja het is toch alleen voor mij dus dat maakt niet echt veel uit.

Dat de thread een minimale tijd nodig heeft daar had ik ook al aan gedacht, het vreemde is dat de hele nanaseconde optie gewoon niets doet. Als ik de delay bijvoorbeeld op 3mS en 500000 nS zou willen zetten zou dat het probleem toch niet moeten zijn.

Maar ja, ik hang nog wel iets van een microprocessor aan de poort, dan moet t allemaal wel goed komen, bedankt allemaal

[Verwijderd]

twilightschild schreef op 18 april 2004 @ 15:33:
Ehm over hoe erg mn code een zooi is, tja het is toch alleen voor mij dus dat maakt niet echt veel uit.

Dat de thread een minimale tijd nodig heeft daar had ik ook al aan gedacht, het vreemde is dat de hele nanaseconde optie gewoon niets doet. Als ik de delay bijvoorbeeld op 3mS en 500000 nS zou willen zetten zou dat het probleem toch niet moeten zijn.

Maar ja, ik hang nog wel iets van een microprocessor aan de poort, dan moet t allemaal wel goed komen, bedankt allemaal

Dus op het moment dat jij er niet uitkomt laat je ons de taak om jouw code te ontcijferen omdat jij geen zin hebt om net te coden?

/me wil niet zeggen dat zijn code altijd netjes is, maar het lijkt me dat je er niet echt lang over hebt nagedacht.

[twilightschild]

Verwijderd schreef op 18 april 2004 @ 16:55:
[...]


Dus op het moment dat jij er niet uitkomt laat je ons de taak om jouw code te ontcijferen omdat jij geen zin hebt om net te coden?

/me wil niet zeggen dat zijn code altijd netjes is, maar het lijkt me dat je er niet echt lang over hebt nagedacht.

Nou kijk, die afkortingen die ik gebruik die slaan gewoon wel allemaal ergens op, maar das misschien niet zo 1,2,3 te volgen.
Verder zijn de dingen als dat ik mn classes niet private maak, of nix doe bij het afvangen van fouten geen probleem bij het begrijpen van het programma.

Zoals ik al zei ben ik geen held in Java.
Misschien moet ik een cursus van een jaar nemen voordat ik mn volgende vraag stel?
En of ik er lang over nagedacht heb? Je moest eens weten hoe lang , maar ik heb gewoon niet genoeg ervaring met Java om alles netjes te kunnen doen. En als ik het mezelf aan het leren ben uit een boek dat alles op een vreemde manier doet, tja dan houdt t snel op.

[Verwijderd]

Ok, das goed. Mss heb je wat aan een paar tips:

• Geef je variabelen en objecten namen waar je wat aan hebt.
(Ik neem aan dat je wel wat beters kunt verzinnen dan w1, a, b en c)

• Voeg wat commentaar toe bij de methoden
(De meeste mensen zullen na enige moeite je code wel kunnen lezen maar wat commentaar is geen overbodige luxe)

• Zet je code in java-specifieke code-tags, dat verhoogt de leesbaarheid.
[code=java]

[EDIT]
Ik had het niet over je code als de manier waarop en wat je gecode hebt. Ik had het over je opmerking met betrekking tot het maken van leesbare code, die is nl een beetje onzin imho.

[ Voor 19% gewijzigd door Verwijderd op 18-04-2004 17:36 ]

[ACM]

Nog een reden om goed leesbare code te maken:
Stel je eens voor dat je over een jaar je code wilt wijzigen. Die "het is toch alleen voor mezelf"-code kan zelfs jij dan nog maar met moeite doorgronden...

Ik heb dat iig een paar keer gehad

[ Voor 3% gewijzigd door ACM op 18-04-2004 18:39 ]

[Alarmnummer]

ACM schreef op 18 april 2004 @ 18:39:
Ik heb dat iig een paar keer gehad

Als ik een OW kon geven dat had ik dat nu gedaan

[Cloud]

Het timing probleem dat je beschrijft, met de nanoseconden en milliseconden is OS afhankelijk. De afronding van de waarde die je geeft word namelijk gedaan door het OS ipv. java zelf. Onder windows bijv. kan je geen sleep kleiner dan 1 mS doen, hij word altijd naar boven afgerond.

Dus zoals al gezegd, wat je nu gebruikt, is de beste oplossing, ookal zou je je code inderdaad ff kunnen optimaliseren.

[ Voor 18% gewijzigd door Cloud op 19-04-2004 11:21 . Reden: toevoeging ]

[Robtimus]

Wolkjeh schreef op 19 april 2004 @ 11:20:
Het timing probleem dat je beschrijft, met de nanoseconden en milliseconden is OS afhankelijk. De afronding van de waarde die je geeft word namelijk gedaan door het OS ipv. java zelf. Onder windows bijv. kan je geen sleep kleiner dan 1 mS doen, hij word altijd naar boven afgerond.

Dus zoals al gezegd, wat je nu gebruikt, is de beste oplossing, ookal zou je je code inderdaad ff kunnen optimaliseren.

Die afronding wordt NIET door het OS gedaan. De source uit java.lang.Thread:

Java:

public static void sleep(long millis, int nanos) 
throws InterruptedException {
    if (millis < 0) {
        throw new IllegalArgumentException("timeout value is negative");
    }

    if (nanos < 0 || nanos > 999999) {
        throw new IllegalArgumentException(
                            "nanosecond timeout value out of range");
    }

    if (nanos >= 500000 || (nanos != 0 && millis == 0)) {
        millis++;
    }

    sleep(millis);
}

In die laatste if statement wordt toch echt wel afgerond.

[Cloud]

Ah klopt Prachtig voorbeeld van verkeerde voorlichting op mijn opleiding Toch staat mij bij dat timing in nanoseconden toch wel mogelijk is. Maar als dit de implementatie van java.lang.Thread inderdaad is, dan heb je in feite niets aan de nanoseconden parameter, omdat deze alleen maar word gebruikt om de milliseconden te verhogen... Vreemd !

[ACM]

Alarmnummer schreef op 18 april 2004 @ 18:52:
Als ik een OW kon geven dat had ik dat nu gedaan

Ik kan me zo voorstellen dat vrijwel alle programmeurs dat wel eens gehad hebben. Ik ken er iig aardig wat die nog wel eens laks met commentaar zijn

Onduidelijke naamgeving maak ik me zelden schuldig aan. Hooguit aan afkortingen die ik later niet helemaal meer terug weet te vertalen

IceManX schreef op 19 april 2004 @ 12:22:
In die laatste if statement wordt toch echt wel afgerond.

Damn, dus die hele parameter is eigenlijk zinloos? Of zal het voor de solaris-VM wel met nano-seconden kunnen werken

[Infinitive]

Mogelijke verklaring: alvast vooruit gedacht. Als we straks met een pentium XXXXI zitten met snelheid 1.0e99 Hz ofzo, dan is het wel handig als je minder dan een miliseconde kan slapen...

[Alarmnummer]

ACM
Ik kan me zo voorstellen dat vrijwel alle programmeurs dat wel eens gehad hebben. Ik ken er iig aardig wat die nog wel eens laks met commentaar zijn

Daar maak ik mezelf ook wel eens schuldig aan, maar ik vind dat je code moet kunnen lezen als een verhaal en in principe moet je code niet vervuild zijn met de wereld comments. Martin Fowler zegt zelfs: extract method als je een comment gebruikt Ik vind zijn oplossing alleen erg onpraktisch omdat je met de wereld kleine methodes zit die alleen een betekenis hebben binnen een bepaalde context.

Infinitive
Mogelijke verklaring: alvast vooruit gedacht. Als we straks met een pentium XXXXI zitten met snelheid 1.0e99 Hz ofzo, dan is het wel handig als je minder dan een miliseconde kan slapen...

Dan had het wel bij de documentatie moeten staan imho: Nanoseconden zijn op dit moment niet mogelijk om in te stellen, maar inde toekomst kan dit veranderen.

Ik had persoonlijk dan gekozen voor alleen 1 argument bij de functie, en tegen de tijd dat een os het wel aankan, dan pas 2 arguments functie pakken (waar je de nanoseconden kan instellen)

[ Voor 60% gewijzigd door Alarmnummer op 19-04-2004 13:28 ]

[Cloud]

Infinitive schreef op 19 april 2004 @ 13:21:
Mogelijke verklaring: alvast vooruit gedacht. Als we straks met een pentium XXXXI zitten met snelheid 1.0e99 Hz ofzo, dan is het wel handig als je minder dan een miliseconde kan slapen...

Dan moeten ze dus nog steeds de implementatie van Thread.sleep(long millis, int nanos) veranderen, want inderdaad, zoals het nu geprogrammeerd is, zijn de nanoseconden overbodig.
Het is een soort brute (zeer overbodige) afrondfunctie, zonder duidelijk nut

ACM schreef op 19 april 2004 @ 13:19:
[...]
Damn, dus die hele parameter is eigenlijk zinloos? Of zal het voor de solaris-VM wel met nano-seconden kunnen werken

Dat vraag ik mij dus ook af, is de implementatie van java.lang.Thread over alle OS' hetzelfde?

[ Voor 23% gewijzigd door Cloud op 19-04-2004 15:33 ]

[Robtimus]

Linux x86 en Windows iig wel.