[Java] Stopwatch Midlet *

[Calvin&Hobbes]

Probleem: de stopwatch stopt niet (ofwel de thread stopt niet met runnen)
En er is geen thread.stop functie aanwezig in Java Mobile, dus heb het geprobeerd met een boolean alleen hoe kan de boolean veranderen als de 2e thread geheel bezig is?

Versimpelde code;

code:

 public void commandAction(Command c, Displayable s) {
    if (c == mExitCommand){
    destroyApp(false);
    notifyDestroyed();
    }
    else if  (c == mStartCommand){
        Starttime =System.currentTimeMillis() ;
        UpdateTimer Utimer = new UpdateTimer();
        secondThread = new Thread( Utimer );
        secondThread.start();
    }

    else if (c == mStopCommand){
        Running = false;    
    }


public class UpdateTimer implements Runnable {
        
    public void run(){
        Running = true;
                while (Running = true) {
                     //Time Stuff
                }

[ Voor 90% gewijzigd door Calvin&Hobbes op 04-07-2008 22:10 ]

[Gerco]

Dat is inderdaad Java, wil je er iets over vragen?

PS. Als je de code tussen [code=java][/code] zet, is het een stuk leesbaarder.

[Sebazzz]

Ja. Je hebt gelijk.

[The - DDD]

Thread scheduling is niet gegarandeerd in Java.

Moet je even opzoeken in de documentatie van de VM die op je mobiel draait.

Ik denk dat Thread.yield() je wel kan helpen. En sowieso wil je op een mobiel niet een spinnende thread hebben.

Ik krijg trouwens een beetje het idee dat je een micro benchmark probeert te schrijven bent. Je weet hoop ik dat dat een over het algemeen slechte manier van testen is in een omgeving met een VM?

[.oisyn]

En is Running wel volatile?

[tweakerbee]

Is het niet makkelijker om gewoon Thread.sleep() aan te roepen en dan daarna even te controleren hoeveel tijd er werkelijk verstreken is? (Thread.sleep() garandeert niet dat ie precies zo lang slaapt.)

[Calvin&Hobbes]

Hoho ik wilde alleen maar een simpele stopwatch schrijven, ben pas sinds 2 uur op de hoogte van threads. Bedoeling is dus dat zodra de stopcommand ingedrukt wordt de boolean Running dus false wordt en ik hoopte dat de thread die bezig is die veranderde voorwaarde ziet (is dus niet zo).

Eigenlijk de 1e stop zoals het hier uitleggen: http://developers.sun.com/mobility/midp/articles/threading2/

[tweakerbee]

Thread.interrupt()?

edit:
riep hij snel zonder naar J2ME gekeken te hebben

En jawel:

As I already mentioned, the stop() and interrupt() methods found in the J2SE Thread class are not available in either J2ME configuration. The stop() method has been deprecated because it is inherently unreliable and cannot be implemented on all platforms safely and consistently. The interrupt() method has been reintroduced in version 1.1 of the CLDC and will probably show up in the next revision of the CDC.

Je zou inderdaad met een volatile boolean vanuit een andere Thread hem moeten kunnen stoppen. Volatile zorgt ervoor dat hij niet ergens in een cache blijft hangen maar echt als gedeelde variabele bekeken wordt.

[ Voor 151% gewijzigd door tweakerbee op 05-07-2008 00:19 ]

[Verwijderd]

Op lijn 22 heb je:

code:

while (Running = true)

Geen idee of het een typo is, maar dit zorgt wel voor een oneindige loop. Je bedoelde waarschijnlijk:

code:

while (Running == true)

[ Voor 5% gewijzigd door Verwijderd op 05-07-2008 00:28 ]

[Calvin&Hobbes]

Verwijderd schreef op zaterdag 05 juli 2008 @ 00:24:
Op lijn 22 heb je:

code:

while (Running = true)

Geen idee of het een typo is, maar dit zorgt wel voor een oneindige loop. Je bedoelde waarschijnlijk:

code:

while (Running == true)

Omg mag ik mijn avond terug , thnx nu kan ik gaan slapen, het werkt (grmbl.. lousy programmernoob at work ) (trouwens volatile of niet, het werkt beide)

[ Voor 13% gewijzigd door Calvin&Hobbes op 05-07-2008 00:33 ]

[The - DDD]

ZOMG... had die assigment ipv. compare ook niet gezien.

Meer info over volatile: http://www.ibm.com/develo...a/library/j-jtp06197.html