Threads

[Donn Cave]

Quoth Terry Hancock <hancock at earthlink.net>:

| I'm writing a scheduler for running "behaviors" under a
| system modelled roughly on "subsumption architectures"
| (Dr. Rodney Brooks and others, check MIT's AI and Robotics
| publications for references to "sumbsumption" and
| "behavior programming").
|
| Basically, it seems very reasonable to run these as
| lightweight processes or "threads," so I'm considering
| using the Python "pthreads" module for posix threading
| in order to do this, but I've never done this before
| and I have some concerns about it:
|
| 1) How broad is "pthreads" support? -- we have a goal
| of this program running on at least Linux, Windows, and
| Mac computers.  Will the code remain portable? What
| platforms don't support pthreads?  Ultimately I'd
| like to run this on embedded systems as well.
|
| 2) Do any of these architectures impose high per-thread
| costs or limits on the number of processes that can be
| running (or rather what are the limits I can expect for
| any architecture?).  I ask this because this programming
| model calls for large numbers (100s or 1000s) of very
| light processes (e.g. 10 - 100 lines of Python code).
|
| The alternative is to simply run the behaviors
| sequentially, without spawning a bunch of separate
| threads, but this is contrary to the design philosophy
| of subsumption architectures, and loses some of their
| advantages (e.g. "fail-soft" resistance to buggy
| behavior code).  The idea is that programs consist
| of large numbers of quasi-independent components which
| can fail without wrecking the rest of the system.
| Processes that "hang up" can just be killed by
| the scheduler when they miss their deadlines.
|
| Also, I'd just like to be aware of any caveats or
| advice you might have about this kind of application.
|
| Thanks a lot!
|
| The project, BTW is http://light-princess.sourceforge.net/
| this is for the "character agents".

Just to be fair and not single out any particular architecture
you mentioned, I tried a simple program on one you didn't, and
under BeOS, 100s of threads isn't a problem but 1000s seems to
be stretching it (I tried 10000, and it didn't execute correctly.)

I don't know of a pthreads module, on any platform.  BeOS doesn't
support pthreads, but the "threads" module works, and the "threading"
module.

>From what I have heard of the stackless microthread system, you
won't get the `processes that "hang up" can just be killed' part
of what you want there, at least not for all causes of hanging up.
Honestly, I guess you won't get it from Python threads either,
because there is no provision in the API for killing a thread, but
at least the process will continue, because these threads go down
to the operating system level where the usual hanging up happens.

	Donn Cave, donn at u.washington.edu