1. True Time Shared Multitasking Success!
Hello again,
After a little experimenting this morning i managed to throw together a
working example of a time shared multitasking 'thread' system. This system
doesnt hog a time slot like the previous version of ThreadManager, but rather
gives each thread one time slice of runtime before forcing the next thread
in line to get it's turn. The result of course is that the threads run in an
order more as expected by most people.
The demo now has three buttons, b1, b2, and b3. b1 starts
thread 1, b2 starts thread 2, and b3 starts thread 3. The threads are
set up as procedures that take no parameters, and get called according
to a thread queue that is created as the user initiates actions in the app.
This means there is now a true scheduler as well, which switches threads
automatically after each respective time slot is up.
Thus, if say the time slice for all threads is 0.1 seconds and all three
threads are started, the order would be:
1,2,3,1,2,3,1,2,3, etc.,
instead of the way it was before (1,2,3,3,3,2,2,1,1).
Here's the status printout from the new demo when the three buttons are
clicked starting with b1, then wait about a second and click b2, then
wait another second and click b3 (and all threads are set up to run
the same time length before ending)...
Thread 1 (started)
Thread 1 running
Thread 1 running
Thread 1 running
Thread 1 running
Thread 2 (started)
Thread 1 running
Thread 2 running
Thread 1 running
Thread 2 running
Thread 3 (started)
Thread 1 running
Thread 2 running
Thread 3 running
Thread 1 running
Thread 2 running
Thread 3 running
Thread 1 running
Thread 2 running
Thread 3 running
Thread 1 running
Thread 2 running
Thread 3 running
Thread 1 running
Thread 2 running
Thread 3 running
Thread 1 running
Thread 2 running
Thread 3 running
Thread 1 running
Thread 2 running
Thread 3 running
Thread 1 running
Thread 2 running
Thread 3 running
Thread 1 running
Thread 2 running
Thread 3 running
Thread 1 running
Thread 2 running
Thread 3 running
Thread 1 running
Thread 2 running
Thread 3 running
Thread 1 running
Thread 2 running
Thread 3 running
Thread 1 running
Thread 2 running
Thread 3 running
Thread 1 running
Thread 2 running
Thread 3 running
Thread 2 running
Thread 3 running
Thread 2 running
Thread 3 running
Thread 2 running
Thread 3 running
Thread 2 running
Thread 3 running
Thread 3 running
Thread 3 running
(this was using 0.2 second time slices)
As can be seen by inspection of above, each thread gets a time to run
before the next thread is switched in, until one or more threads complete
at which time that thread is eliminated from the queue.
In general, it took one more function call to get fairly simple operation,
but the required structure is a little more complex in that the user has
to set up procedures that get called when their time comes, and there's
also a required "AllThreadsDone" procedure that has to be declared so
that the user gets notified when all threads are completed.
What this means is that it's a little harder to use this method than
the previous LIFE method, although not as hard as i thought it would be.
It does even appear that the setup structure for deciding on chunk size
will actually be easier with this new method, which is nice.
The required function calls are now:
StartThread()
EnterThread()
LeaveThread()
EndThread()
That's not too bad i guess.
Another benefit is that the new test call (LeaveThread) is very fast,
so it wont slow down normal operations (like when saving files).
Now to clean up the files a bit :)
I guess i'll call this ThreadManager02, but i'll be sure to include
notes to explain to users that it's still not OS threads.
Sound good or no?
Comments welcome!
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
2. Re: True Time Shared Multitasking Success!
- Posted by "Kat" <gertie at visionsix.com>
Aug 13, 2005
-
Last edited Aug 14, 2005
On 13 Aug 2005, at 8:45, Al Getz wrote:
>
>
> posted by: Al Getz <Xaxo at aol.com>
>
> Hello again,
>
>
> After a little experimenting this morning i managed to throw together a
> working example of a time shared multitasking 'thread' system. This system
> doesnt hog a time slot like the previous version of ThreadManager, but rather
> gives each thread one time slice of runtime before forcing the next thread in
> line to get it's turn. The result of course is that the threads run in an
> order
> more as expected by most people. The demo now has three buttons, b1, b2, and
> b3.
> b1 starts thread 1, b2 starts thread 2, and b3 starts thread 3. The threads
> are set up as procedures that take no parameters, and get called according to
> a
> thread queue that is created as the user initiates actions in the app. This
> means there is now a true scheduler as well, which switches threads
> automatically after each respective time slot is up. Thus, if say the time
> slice
> for all threads is 0.1 seconds and all three threads are started, the order
> would be:
> 1,2,3,1,2,3,1,2,3, etc.,
> instead of the way it was before (1,2,3,3,3,2,2,1,1).
>
> Here's the status printout from the new demo when the three buttons are
> clicked starting with b1, then wait about a second and click b2, then
> wait another second and click b3 (and all threads are set up to run
> the same time length before ending)...
>
<snip>
> (this was using 0.2 second time slices)
>
> As can be seen by inspection of above, each thread gets a time to run
> before the next thread is switched in, until one or more threads complete
> at which time that thread is eliminated from the queue.
>
> In general, it took one more function call to get fairly simple operation,
> but the required structure is a little more complex in that the user has
> to set up procedures that get called when their time comes, and there's
> also a required "AllThreadsDone" procedure that has to be declared so
> that the user gets notified when all threads are completed.
> What this means is that it's a little harder to use this method than
> the previous LIFE method, although not as hard as i thought it would be.
> It does even appear that the setup structure for deciding on chunk size
> will actually be easier with this new method, which is nice.
> The required function calls are now:
> StartThread()
> EnterThread()
> LeaveThread()
> EndThread()
> That's not too bad i guess.
> Another benefit is that the new test call (LeaveThread) is very fast,
> so it wont slow down normal operations (like when saving files).
>
>
> Now to clean up the files a bit :)
>
> I guess i'll call this ThreadManager02, but i'll be sure to include
> notes to explain to users that it's still not OS threads.
>
> Sound good or no?
Sounds good to me! 
> Comments welcome!
Can one set "thread" priority, and get back elapsed_time_to_completion if
available, from the threads?
Kat
3. Re: True Time Shared Multitasking Success!
Kat wrote:
>
> On 13 Aug 2005, at 8:45, Al Getz wrote:
>
> >
> > posted by: Al Getz <Xaxo at aol.com>
> >
> > Hello again,
> >
> >
> > After a little experimenting this morning i managed to throw together a
> > working example of a time shared multitasking 'thread' system. This system
> > doesnt hog a time slot like the previous version of ThreadManager, but
> > rather
> > gives each thread one time slice of runtime before forcing the next thread
> > in
> > line to get it's turn. The result of course is that the threads run in an
> > order
> > more as expected by most people. The demo now has three buttons, b1, b2, and
> > b3.
> > b1 starts thread 1, b2 starts thread 2, and b3 starts thread 3. The
> > threads
> > are set up as procedures that take no parameters, and get called according
> > to a
> > thread queue that is created as the user initiates actions in the app. This
> > means there is now a true scheduler as well, which switches threads
> > automatically after each respective time slot is up. Thus, if say the time
> > slice
> > for all threads is 0.1 seconds and all three threads are started, the order
> > would be:
> > 1,2,3,1,2,3,1,2,3, etc.,
> > instead of the way it was before (1,2,3,3,3,2,2,1,1).
> >
> > Here's the status printout from the new demo when the three buttons are
> > clicked starting with b1, then wait about a second and click b2, then
> > wait another second and click b3 (and all threads are set up to run
> > the same time length before ending)...
> >
>
> <snip>
>
> > (this was using 0.2 second time slices)
> >
> > As can be seen by inspection of above, each thread gets a time to run
> > before the next thread is switched in, until one or more threads complete
> > at which time that thread is eliminated from the queue.
> >
> > In general, it took one more function call to get fairly simple operation,
> > but the required structure is a little more complex in that the user has
> > to set up procedures that get called when their time comes, and there's
> > also a required "AllThreadsDone" procedure that has to be declared so
> > that the user gets notified when all threads are completed.
> > What this means is that it's a little harder to use this method than
> > the previous LIFE method, although not as hard as i thought it would be.
> > It does even appear that the setup structure for deciding on chunk size
> > will actually be easier with this new method, which is nice.
> > The required function calls are now:
> > StartThread()
> > EnterThread()
> > LeaveThread()
> > EndThread()
> > That's not too bad i guess.
> > Another benefit is that the new test call (LeaveThread) is very fast,
> > so it wont slow down normal operations (like when saving files).
> >
> >
> > Now to clean up the files a bit :)
> >
> > I guess i'll call this ThreadManager02, but i'll be sure to include
> > notes to explain to users that it's still not OS threads.
> >
> > Sound good or no?
>
> Sounds good to me!
>
> > Comments welcome!
>
> Can one set "thread" priority, and get back elapsed_time_to_completion if
> available, from the threads?
>
> Kat
>
>
Hi there Kat,
Right now this is like a "first generation" time sharing multitasker,
which provides the basic functionality needed to process multiple
threads the way most people would expect them to be done. There is,
however, an indirect way to set priority of each individual thread,
and even to change that priority while running by simply assigning
a lower or higher value for the time slice.
I suppose there are many additions that could be added now that
the basic multitasker is working such as "WaitForThread(x)" and
things like that. I suppose there would be a way to estimate
time-to-completion but i havent even considered that yet :)
There is a simple way to estimate TTC of a single slice though.
Oh yeah, for what it's worth, i made a mistake when i posted the
four required function calls...instead of:
StartThread()
EnterThread()
LeaveThread()
EndThread()
they are actually named:
StartThread()
EnterThread()
QueryLeaveThread()
EndThread()
This turned out much easier than i had imagined, but the user does
have to set up procedures that get called for each thread. That
wasnt required with the simpler version (TM01).
I set the demo up with procedures named Thread1(), Thread2(), and
Thread3() although any names can be used of course.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
