Re: Someone changed my Thread Manager writeup?
Hello again,
I didnt get to finish replying to Rob's post...
Rob:
QUOTE
Your "thread manager"
- does not support O/S (pre-emptive) threads in any way
Many people assume that if something is called a "thread"
it uses pre-emptive O/S threads.
- does not have a separate call stack for each "thread".
That seems to be the bottom line for any form of threading or
tasking that you'll find discusssed on the Web
- has no scheduler. i.e. no way of specifying the timing of
when a "thread" should run (other than the user clicking something),
and no way of setting priorities
- transfers control from one "thread" to another via call/return
so a thread can only get control after a return from all the other
stacked calls to other "threads", including possible calls
to itself.
END QUOTE
It does in fact use:
"Preemptive Multitasking"
ie uses some criteria to decide how long any one task should run before
giving another task a turn to use the operating system.
Although it's not *ALL* built into the "ThreadManager" the recommended
structure for using this technique makes it preemptive.
Note the time() calls in the ThreadManager.
Again, although the ThreadManager itself doesnt contain a separate call
stack, the 'call stack' comes from the way the structure of the
way the Thread Manager is used (noted in the docs). Each entry into the
long operation function creates another pseudo 'stack'. Each thread
thus has it's own 'stack'. Other perhaps required variables may be
allocated if they are done private to the function call or using allocated
memory.
It does in fact have a scheduler...as noted before...it's just not
your 'usual' time slice mechanism. It's a last-in-first-complete schedual.
A new thread may start at any time once the time slice for the current
thread is complete...even though the entire operation of the thread isnt
yet done. Although this isnt your usual 'poll each thread' type
mechanism, to the user it looks almost the same.
Transfer of control from one 'thread' to another takes place when the
next operation is initiated. The new thread takes over and when it's
complete operation continues with the previously invoked thread.
When that thread is complete the thread before that then takes control.
Thus, if threads are initiated in this order:
1-2-3
they complete in this order:
3-2-1
Note that if thread 2 is almost done when thread 3 is initiated,
after thread 3 is complete thread 2 completes rather quickly
because it's almost done.
Note also that the demo allows multiple calls to the same 'thread' that
initiates a new thread, but in practice this might actually be blocked
by maintaining a variable to allow or prevent re-entry. For the
demo i thought it would be easier for the user to see more threads
being initiated by simply clicking the same button over and over.
I still agree however that more of an explanation would have been
better, but would like to see other users try this method before
thinking that it's not very good.
As i mentioned in a earlier post, i've used a similar technique
in a calculator program and geeze, it's like having 20 calculators
working at the same time even though there's only one gui :)
I've also used a similar technique in a C based chess program,
where some operations have to complete before the user can exit
and the gui has to be active at all times (to allow takeback while
the computer is thinking, etc.) and it looks like it's multi threaded.
Now maybe this helps explain why i said in my initial writeup:
"Dont let this small 1200 byte ThreadManager fool you" :)
Ok, so part of the 'trick' is in the structure and use of
the ThreadManager, but it's not hard to use.
I think it actually does quite a bit, and it's small, which makes
it look like it doesnt do much.
Take care,
Al
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
|
Not Categorized, Please Help
|
|
