Lunacy or Stupidity?



  •  I can't tell whether this lunacy or stupidity: 

     

    while (true)
    {
        long time_ = Calendar.getInstance().getTimeInMillis();
        mInterval = time_ - mPrevTime;
        if ((mInterval > mSleepTime) || (mPrevTime == 0))
        {
            //do some stuff
            mPrevTime = Calendar.getInstance().getTimeInMillis();
        }
    }

     

    Time for you to pull it apart.....




  • I had to add this from the "do some stuff" section:

        pr("Updating. ID = "+(mLastId+1));
        Hashtable[] res = mysql.get("select some_field from some_table where the_id  = "+(mLastId+1)); 

    DB identifiers were sanitized, pr() is a function which just echos whatever is passed to it.

    Is it not possible that there may be a record that is just deleted. Oh, and there were, and the app was stuck querying for a non-existant record (while future ones did exist) eating up CPU. I think, overall, it makes for a great burn-in app.

     



  • So it's a not-so-good loop designed to sleep for an interval, wake up and do something, and then go back to sleep.  (I assume the Java APIs include some sort of Sleep() function, but it's been a decade since I've been in there.)  I'm not following the lunacy, since nothing you've described so far looks like a problem.  Your commentary about the SQL doesn't make the issue any clearer in my mind.



  • @mrprogguy said:

    So it's a not-so-good loop designed to sleep for an interval, wake up and do something, and then go back to sleep.  (I assume the Java APIs include some sort of Sleep() function, but it's been a decade since I've been in there.)  I'm not following the lunacy, since nothing you've described so far looks like a problem.  Your commentary about the SQL doesn't make the issue any clearer in my mind.

    Thread.Sleep(), but that can throw an interrupt exception. And we know how bad exceptions are, and have you ever been interrupted in your sleep? That's hell.

    Also, by making your software sleep it might not be in time, because it can oversleep. And all those snort naps are not good for him.



  • @Daid said:

    @mrprogguy said:

    So it's a not-so-good loop designed to sleep for an interval, wake up and do something, and then go back to sleep.  (I assume the Java APIs include some sort of Sleep() function, but it's been a decade since I've been in there.)  I'm not following the lunacy, since nothing you've described so far looks like a problem.  Your commentary about the SQL doesn't make the issue any clearer in my mind.

    Thread.Sleep(), but that can throw an interrupt exception. And we know how bad exceptions are, and have you ever been interrupted in your sleep? That's hell.

    Also, by making your software sleep it might not be in time, because it can oversleep. And all those snort naps are not good for him.
     


    Busy waiting is bad in just about all user space code, and especially from with a managed environment.  Also, by virtue of the fact that this is java a busy wait makes absolutely no guarantees as to the timing of when a perticular event may occur because the VM may stop the thread to run a garbage collection cycle or something.  Even in a non-managed environment, the OS could still preempt the process once again throwing out any time guarantees.



  • @mrprogguy said:

    So it's a not-so-good loop designed to sleep for an interval, wake up and do something, and then go back to sleep.  (I assume the Java APIs include some sort of Sleep() function, but it's been a decade since I've been in there.)  I'm not following the lunacy, since nothing you've described so far looks like a problem.  Your commentary about the SQL doesn't make the issue any clearer in my mind.

    Thread.sleep() is one. If you want a better guarantee on your app waking up at the right time, you can use a TimerTask for repetitive tasks.


  • @mrprogguy said:

    So it's a not-so-good loop designed to sleep for an interval, wake up and do something, and then go back to sleep.

    I think the main problem is that it doesn't really sleep.

    If we can assume than the code never breaks out of the loop, then mInterval is almost always 0, except perhaps for the first iteration. (since the current time is assigned to mPrevTime at the bottom of the loop, immediately before the current time is assigned to time_ at the top of the loop). And when mInterval is 0, the 'if' is being executed, so there is no real sleeping going on at all (except in the rare instances where the clock ticks exactly inbetween setting mPrevTime and setting time_).

    Perhaps it did busywait-sleep originally, but someone decided that it shouldn't, and altered the code in this nice and hackish way..? *bows to the author*



  • I prefer Thread.sleep()........

    Polling in a loop like that is going to eat up the cpu at 100% (per core) while it is 'waiting'. So a newbie doesn't know about Thread.sleep, which would fall under the stupidity category....? or maybe he is crazy and only wants that shit to run at 100%... maybe he doesn't have a heater in his office and when that cpu cranks up it warms his cubicle.



  • WTF LOL, never post just before you're going to bed. I somehow managed misread the second condition as "mInterval == 0". *bows to myself*

    Ok, not the giant WTF i first thought (hoped).


Log in to reply