OpenEuphoria

1. Multitasking: active waiting!?

• Posted by Ryan W. Johnson <ryanj at fluidae.com> Apr 18, 2006
• 463 views

Rob: I tried the new multitasking routines, and i realized that the CPU is at
100% even though the tasks are not running all the time.

task_schedule(task_kernMain_HighPri, {0.005, 0.01})
task_schedule(task_kernMain_LowPri, {0.5, 1})
   task_schedule(task_kernMain_100ms, {0.1, 0.1})
   task_schedule(task_kernMain_500ms, {0.5, 0.5})
   task_schedule(task_kernMain_1s, {1, 1})
   task_schedule(task_kernMain_2s, {2, 2})
   task_schedule(task_kernMain_10s, {10, 10})
   task_schedule(task_kernMain_60s, {60, 60})

~Ryan W. Johnson

Fluid Application Environment
http://www.fluidae.com/

[cool quote here, if i ever think of one...]

3. Re: Multitasking: active waiting!?

• Posted by Ryan W. Johnson <ryanj at fluidae.com> Apr 18, 2006
• 461 views

Grrr....i just can't type tonight...i think i need sleep...

I thought I should say, I do like the new multitasking feature, but if it does
active waiting, then that's just not good.

I like the new features you are considering/implementing
(http://rapideuphoria.com/future.htm) and I'm looking forward to version 3.0!
I'll definitely register it. 
~Ryan W. Johnson

Fluid Application Environment
http://www.fluidae.com/

[cool quote here, if i ever think of one...]

5. Re: Multitasking: active waiting!?

• Posted by Ryan W. Johnson <ryanj at fluidae.com> Apr 19, 2006
• 500 views

Robert Craig wrote:
 
> The way it works at the moment, the Euphoria task scheduler 
> calls sleep() only when there is a gap of at least 1 second
> until the next task is due to resume. That's because sleep() only
> has a resolution of 1 second (that's the worst case 
> across all platforms). For smaller gaps it just spins its 
> wheels in a loop. 

That's what i thought was happening.

> It might be wasteful to sleep for a tiny fraction of a second, 
> giving up control, and hoping the O/S will give it back in time. 
> Also, other than DOS, the O/S should be able to grab control 
> pre-emptively whenever it wants to run another process, 
> regardless of whether you are sleeping or not.

The problem I have with that is the program is hogging all the available CPU
instead of letting the CPU idle. It's true that the OS can still give other
processes a chance to run, but the point is it's not letting the CPU idle like it
should be when it's not "doing" anything.

I'm wondering how well it would work if the scheduler tried to sleep for short
intervals (perhaps 0.01 s).

Here's an idea: if you made the sleep() procedure more precise, then the
programmer could easily create an idle task. 

global procedure idle(atom idletime)
   while 1 do
      sleep(idletime)
      task_yield()
   end while
end procedure

task_idle = task_create(routine_id("idle"), {0.01}) --create task to idle for
0.01 seconds.
task_schedule(task_idle, {1}) --time-shared task

"Real-time tasks have a higher priority. Time-shared tasks are run when no
real-time task is ready to execute."
If i understand this correctly, the above code would call the task_idle() only
when real-time tasks are not scheduled to run, right?

If you think it's a good idea, perhaps idle() could even be a built-in routine.
What do you think about all this, Rob?

~Ryan W. Johnson

Fluid Application Environment
http://www.fluidae.com/

[cool quote here, if i ever think of one...]

7. Re: Multitasking: active waiting!?

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Apr 19, 2006
• 461 views

Robert Craig wrote:
> 
> Ryan W. Johnson wrote:
> > Rob: I tried the new multitasking routines, and i realized that the CPU is
> > at
> > 100% even though the tasks are not running all the time. Here is how i set
> > up
> > the scheduling:
> > 
> > }}}
<eucode>
> >    task_schedule(task_kernMain_HighPri, {0.005, 0.01})
> >    task_schedule(task_kernMain_LowPri, {0.5, 1})
> >    task_schedule(task_kernMain_100ms, {0.1, 0.1})
> >    task_schedule(task_kernMain_500ms, {0.5, 0.5})
> >    task_schedule(task_kernMain_1s, {1, 1})
> >    task_schedule(task_kernMain_2s, {2, 2})
> >    task_schedule(task_kernMain_10s, {10, 10})
> >    task_schedule(task_kernMain_60s, {60, 60})
> > }}}
<eucode>
> > 
> > Even if i change the first line to {0.5, 1} it still maxes the CPU.
> > Shouldn't
> > euphoria allow the program to sleep between tasks, even if only for 0.01
> > seconds? I just cannot use this
> if it's gonna how the CPU!
> 
> The way it works at the moment, the Euphoria task scheduler 
> calls sleep() only when there is a gap of at least 1 second
> until the next task is due to resume. That's because sleep() only
> has a resolution of 1 second (that's the worst case 
> across all platforms). For smaller gaps it just spins its 
> wheels in a loop. 
> 
> It might be wasteful to sleep for a tiny fraction of a second, 
> giving up control, and hoping the O/S will give it back in time. 
> Also, other than DOS, the O/S should be able to grab control 
> pre-emptively whenever it wants to run another process, 
> regardless of whether you are sleeping or not.
>  
> > This brings up another point that i meant to bring up a long time ago:
> > could you change sleep() so that it could have a higher resolution, such as
> > 0.01 seconds?
> 
> Yes, I would like to have a higher-resolution sleep(), and I will
> look into it. I don't think all the various C compiler libraries
> provide that directly though.
> 
> Thanks,
>    Rob Craig
>    Rapid Deployment Software
>    http://www.RapidEuphoria.com

For Windows, you don't need to worry about what the compiler provides. 
Just call SleepEx from kernel32.dll, it is supported from Win95 up, and
bypass the compiler wrapper so that the code won't depend on the compiler.

Under DOS, you can insert some machine code which will give you more than 
the resolution you wish. An Euphoria version exists in the archive as CPUTime,
and you are only left with inlining the asm stuff, which may be
compiler-dependent.
The code will work on any Pentium 1+ machine.

There remains the issue of multitasking under pure DOS on 486- machines. 
Does that issue even make sense? 
If it does, you can always program the interval timer with a bit more machine 
code; the only issue here will be trapping int #70 (CMOS IRQ) in protected 
mode, because the required mode switch may take a few microseconds. Further, 
this could interfere with handling of the internal speaker (beep freq/duration),
but I'd have to dig more to assess this.

Regards
CChris

9. Re: Multitasking: active waiting!?

• Posted by Robert Craig <rds at RapidEuphoria.com> Apr 19, 2006
• 447 views

Ryan W. Johnson wrote:
> Robert Craig wrote:
> > The way it works at the moment, the Euphoria task scheduler 
> > calls sleep() only when there is a gap of at least 1 second
> > until the next task is due to resume. That's because sleep() only
> > has a resolution of 1 second (that's the worst case 
> > across all platforms). For smaller gaps it just spins its 
> > wheels in a loop. 
> 
> That's what i thought was happening.
> 
> > It might be wasteful to sleep for a tiny fraction of a second, 
> > giving up control, and hoping the O/S will give it back in time. 
> > Also, other than DOS, the O/S should be able to grab control 
> > pre-emptively whenever it wants to run another process, 
> > regardless of whether you are sleeping or not.
> 
> The problem I have with that is the program is hogging all the available CPU
> instead of letting the CPU idle. It's true that the OS can still give other
> processes a chance to run, but the point is it's not letting the CPU idle like
> it should be when it's not "doing" anything.
> 
> I'm wondering how well it would work if the scheduler tried to sleep for short
> intervals (perhaps 0.01 s).

.01 seconds would be preferable to 1 second. 
I'll see what I can do.
 
> Here's an idea: if you made the sleep() procedure more precise, then the
> programmer could easily create an
> idle task. 
> 
> }}}
<eucode>
> global procedure idle(atom idletime)
>    while 1 do
>       sleep(idletime)
>       task_yield()
>    end while
> end procedure
> 
> task_idle = task_create(routine_id("idle"), {0.01}) --create task to idle for
> 0.01 seconds.
> task_schedule(task_idle, {1}) --time-shared task
> </eucode>
{{{

> 
> "Real-time tasks have a higher priority. Time-shared tasks are run when no
> real-time
> task is ready to execute."
> If i understand this correctly, the above code would call the task_idle() only
> when real-time tasks are not scheduled to run, right?

Right. The scheduler's first priority is to meet any 
real-time scheduling demands. When it has a gap in the real-time schedule,
it runs time-shared tasks.
 
> If you think it's a good idea, perhaps idle() could even be a built-in
> routine.

Perhaps, but I don't like to predefine simple routines 
that the programmer can easily define for him/herself.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com