Re: True Time Shared Multitasking Success!
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
|
Not Categorized, Please Help
|
|
