1. marry christmas
- Posted by richard koch <dr.richard.koch at t-online.de>
Dec 25, 2005
-
Last edited Dec 26, 2005
hi,
marry christmas to you all!
i am excited watching the thtread about MT - get me an all new perspective.
not having followed the whole scenario, is it like threads? get a connetion
and spawn a process that will be encapsulated and run unempeded, no destraction
from extern - and will compelet witout interuption?
loop
conditon
spawn - process/thread
end conditon -- never mind the thread
end loop
never the less - marry christmas and a happy new year
craig -- right way
richard
2. Re: marry christmas
richard koch wrote:
>
> hi,
> marry christmas to you all!
> i am excited watching the thtread about MT - get me an all new perspective.
> not having followed the whole scenario, is it like threads? get a connetion
>
> and spawn a process that will be encapsulated and run unempeded, no
> destraction
>
> from extern - and will compelet witout interuption?
>
> loop
> conditon
> spawn - process/thread
> end conditon -- never mind the thread
> end loop
>
> never the less - marry christmas and a happy new year
> craig -- right way
>
>
> richard
The system RDS is implementing into Euphoria is called cooperative
multi-tasking. This method is different from pre-emptive multitasking in that a
scheduled task manager determinds when its appropriate for it to interrupt a
currently executing task then give control to another *OR* continue with the
current task. The task manager must first have permission to make this
determination with calls to task_yield().
My personal assessment of such a system concludes big disadvantages with the
latest computer technology and will become an inferior and obsolete standard in
the near future, if not currently. Fortuantly there may be an alternative
solution for Euphoria and any other language that does not support threads,
however it is not without it's own different problems. Nevertheless i'll likely
favor the latter without hesitation after some further experimentation.
Merry Christmas. 
Regards,
Vincent
3. Re: marry christmas
Vincent wrote:
>
> richard koch wrote:
> >
> > hi,
> > marry christmas to you all!
> > i am excited watching the thtread about MT - get me an all new perspective.
> > not having followed the whole scenario, is it like threads? get a connetion
> >
> > and spawn a process that will be encapsulated and run unempeded, no
> > destraction
> >
> > from extern - and will compelet witout interuption?
> >
> > loop
> > conditon
> > spawn - process/thread
> > end conditon -- never mind the thread
> > end loop
> >
> > never the less - marry christmas and a happy new year
> > craig -- right way
> >
> >
> > richard
>
> The system RDS is implementing into Euphoria is called cooperative
> multi-tasking.
> This method is different from pre-emptive multitasking in that a scheduled
> task
> manager determinds when its appropriate for it to interrupt a currently
> executing
> task then give control to another *OR* continue with the current task. The
> task
> manager must first have permission to make this determination with calls to
> task_yield().
>
> My personal assessment of such a system concludes big disadvantages with the
> latest computer technology and will become an inferior and obsolete standard
> in the near future, if not currently. Fortuantly there may be an alternative
> solution for Euphoria and any other language that does not support threads,
> however it is not without it's own different problems. Nevertheless i'll
> likely
> favor the latter without hesitation after some further experimentation.
>
> Merry Christmas.
>
>
> Regards,
> Vincent
Hi Vincent,
My own task stuff is basically the same thing: either there is a function
that must be called mid-task or else the 'task' has to return (temporarily)
to allow the system to make another determination.
I havent found this to be a problem because when i write the code i can
insert some sort of task yielding call or write the task so it's embodied
inside a procedure or function that returns temporarily to allow the
system to respond.
Problem is, if i didnt write the code then there's no way to yield so these
methods fail as you noted, but another work around might be to write
a server instead of a program (or even two or more servers) and have the
main program work with the server(s). I've done this already with one
of my programs called "In Place Scientific Calculator", which is basically
a function calculator engine wrapped as a server.
Once you create a server, you can have programs interacting through
the server, share data, as well as post messages (so they dont have to
wait around for the return value). Since the server runs in a different
process it's got to be thread independent of the main program.
If this is to your liking, perhaps you can try this method using Euphoria.
As noted, it's got some benefits that go beyond threads alone too...
another one is that the server does not crash even if the main program does,
so any data saved through the server is still resident and accessable
through the main program (once it's started again).
If you end up doing something like this i'd like to hear about
your experiences with it.
Take care, and happy holidays,
Al
P.S. Seems we have a lot of different spellings of
"Merry Christmas" this year
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
4. Re: marry christmas
- Posted by Vincent <darkvincentdude at yahoo.com>
Dec 27, 2005
-
Last edited Dec 28, 2005
Al Getz wrote:
>
> Hi Vincent,
>
> My own task stuff is basically the same thing: either there is a function
> that must be called mid-task or else the 'task' has to return (temporarily)
> to allow the system to make another determination.
> I havent found this to be a problem because when i write the code i can
> insert some sort of task yielding call or write the task so it's embodied
> inside a procedure or function that returns temporarily to allow the
> system to respond.
> Problem is, if i didnt write the code then there's no way to yield so these
> methods fail as you noted, but another work around might be to write
> a server instead of a program (or even two or more servers) and have the
> main program work with the server(s). I've done this already with one
> of my programs called "In Place Scientific Calculator", which is basically
> a function calculator engine wrapped as a server.
> Once you create a server, you can have programs interacting through
> the server, share data, as well as post messages (so they dont have to
> wait around for the return value). Since the server runs in a different
> process it's got to be thread independent of the main program.
> If this is to your liking, perhaps you can try this method using Euphoria.
> As noted, it's got some benefits that go beyond threads alone too...
> another one is that the server does not crash even if the main program does,
> so any data saved through the server is still resident and accessable
> through the main program (once it's started again).
>
> If you end up doing something like this i'd like to hear about
> your experiences with it.
Hi Al,
Your server IPC method sounds interesting... perhaps I'll experiment with it
too.
I currently testing out a Memory Mapped File IPC (shared memory) method. I was
wrapping the Win32 Mutex and Semaphore synchronization API, but quickly noticed
that Patrick Barnes has already done it. A Linux and FreeBSD port is still needed
though.
I successfully written a simple multi-process program that communicates between
five blocks of shared memory. The program consists of three main files and one
loader file. Assuming all four processes have high enough priority and CPU usage,
Windows should place each process on a seperate core with quad-core and quad
processor systems *or* dual-core /w Hyper-Threading and dual processor /w
Hyper-Threading systems. Since all the processes can share data and rely on each
other for computation, true parralelism might be possible on those systems. Of
course on single core, single processor systems, only hardware-level context
switching can occur.
In general, multi-process programming is less efficent than multi-thread
programming in Windows because context switching between processes is more
expensive than with threads; but at least we *might* have alternatives to
cooperative multi-tasking in the future (until Rob implements true
thread-safety).
Regards,
Vincent
