In article <871pq0uppw.fsf@nightsong.com>,
Paul Rubin wrote:
>Question is how to multitask on a small embedded target. One way is the
>traditional cooperative multitasker with a shared dictionary plus task
>variables.
>
>Another way is time slicing multiple interpreters, each with its own
>data dictionary (all variables are task variables). There would be a
>shared read-only dictionary for code and constants, and a mailbox scheme
>for IPC.
>
>This question is more about shared vs non-shared than cooperative vs
>preemptive. The latter would be Erlang-style preemptive, i.e. avoiding
>most locking hazards by using mailboxes instead of memory sharing.
>
>Does anyone do it this way? Is the overhead substantial?
Interpreting a musical score with multiple instruments
and several polyphonic parts:
If I look at the manx program, I have 2 levels of multitasking.
The low level for the instruments (microseconds precision and busy
waiting) and the high level , interpreting a measure of a part of a
musical score than the same measure of other parts.
Once the low level queues are full, and the next event is -- say --
15 mS away, I give time back to the OS (linux) by a wait, such that
the process can be run in the background and the terminal is still
responsive.
Without waiting this can be run on a small system, memory may
restrict the size of the musical score.
This suggests that a Forther would design the multitasking fit
for the application,
The other situation is that you take advantage of multiple cores
to speed up the calculation. There you use the fork system call.
Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
