- From: Svanberg Liss <lisss ydab se>
- To: "GNOME - devel list (E-post)" <gnome-devel-list gnome org>
- Subject: Bio-scheduler
- Date: Mon, 29 Nov 1999 12:01:16 +0100
Perhaps this isn't the right list to ask about these things, but I don't
really know what kind of list would be the correct one.
Besides, in the end, the project IS gnome-related...
I have an "biological" algorithm.
I have got a lot of "individuals" - small programs that are supposed to
interact somewhat whith eachother.
All "individuals" share the same CPU time, and the same resources.
Each "individual" can be preempted by another "individual", or with other
words, each "individual" are only allowed to run for a short time, then the
CPU is passed on to the next one.
There is no priority differences between them, so there is no need for some
advanced scheduling algorithms.
A longer program will simply take longer to finish, a large program will
simply take more memory.
My question is: What would the best way to code this be?
The obvious would perhaps be to run each "individual" as an individual
thread or process.
The problem here is that a very small system will have at least 10.000
"individuals", and a normal one would have 100.000 or more...
( My linux pukes after 1024 processes. Not that I have checked, but the code
says so... :)
The only similar project I have herad about is the "Tierra project". They
have invented their own "machine-code" wich runs in their own "virtual
machine" with their own "operating system"...
A little note for those that didn't know: Biological or evolutional
algorithms usually work by selections of enourmous numbers of units. The
larger number of units to select from, the better. 100.000 units is in fact
So far, I have used a big queue where I have stored intermediate results
from the "individuals", and tried to write the "individuals" so that they
can be abradoned and resumed. It appears to work, but code quickly becomes
wery ugly and hard to maintain, especially if the code contains recursive
parts. So it isn't the wery best approach...
I have played with the thought that I could write a module-plugin to tthe
linux kernel, that takes the role of a cheap non-realtime round-robin
all-the-same-priority "scheduler", but such a soulution would be rather
non-portable. Not to mention that I would have to debug code in
Anybody that have some kind of idea, or that has worked in a similar
Using an event queue like the one in Gtk+ ?
( You doesn't happen to know about some portable library that allows you to
switch stack? Then I could use one "custom stack" per "individual" and
preemt them with signals... :)
/* liss */
] [Thread Prev