Lots of concurrency

Andres Valloud sqrmax at prodigy.net
Fri Oct 26 16:28:08 UTC 2001


Hi.

> Yes it is a parallel world and I'll take your word for it that
> "people clearly don't think sequentially" but we also clearly
> structure our daily activities sequentially. Check anybodies to-do
> list. Some people, circus performers and manager, can juggle several
> activities. The fact they can is regarded as a notable feat, not the
> natural order of things. Moreover we model the world as system of
> interacting sequential agents. Other people out there are performing
> their own activities sequentially.

IMHO, and FWIW, I think the key here is to come up with a definition of
what is to think.  Certainly there's many processes running in the brain
which we usually ignore even though they keep us alive.  Some others run
even without the possibility of being observed.  Would we call all that
to think?

Descartes said "I think, therefore I am".  Maybe a more illuminating
thing to say in this context would be "I experience self-consciousness,
therefore I am".  If we go down that road, then many things seem more
clear.

Our self-consciousness "processor" runs threads.  Threads tap on shared
brain resources, they also have a dedicated storage space we may refer
to as its state.  The running thread can be interrupted by other
threads.  Any interrupting thread may become the running thread. 
Threads may call other threads, return, terminate, etc.  Keeping a
thread stack requires concentration.

There are many threads which are either suspended or that run just while
interrupting the consciousness thread.  These threads are the ones which
we can be conscious about.  There are also other threads which we can
only observe or communicate to, there are threads we can't observe at
all.

The processor runs two threads which provide us the magic of
self-consciousness: an observer/scheduler thread, and an observed
thread.  The role of the observer/scheduler is to literally observe and
schedule the observed thread.  The observed thread is usually a
particular interface to the resources of the brain.  These threads are
usually the ones we say that think.

The sense of identity comes from the observer thread.  It is where the
decision regarding who we are is made, it's also where we interpret our
perceptions according to our intentions.

All this would be better if I could replace the terms processor and
thread with something that corresponded better to what happens in the
brain.

> So if we're going to use this analogy to design programming
> languages we want a language that provides for robust interaction
> of many sequential tasks operating in parallel, without the need
> for a lot of centralized control.

Where does intention fit in the many processes running in parallel
picture?  Maybe the problem is that managing a big collection of
parallel tasks without an intention thread is just a mess.  It all boils
down to modeling intention.  What is it and how do we make it more
explicit?

I feel most of (all?) the software ever written is an *expression* of
intention, a consequence.  Intention per se is nowhere to be found in
the source code.  When we read other people's source, we understand by
figuring out the intentions -> intention revealing code is easier to
understand because we see the context in which the code was written in
the first place.  Only then we understand.

> The problem with today's state of the art seems to be that our
> software entities don't have sufficient understanding of the
> protocols required to operate in a parallel environment. In turn
> the environment doesn't have the requisite institutions and
> structures to allow independent parallel entities to operate.

I think that #fork, #when:send:to: and a bunch of small practices are
more than enough for this.  The key here is that intention is usually
not revealed.  We want a bunch of threads in software, just like we
perceive a bunch of threads in our heads.  But without an observer
thread, without modeling intention and making it explicit, many threads
just don't seem to make much sense.

A single thread, on the other hand, gives us the view of the world from
the observer thread point of view.  Since, AFAIK, with computers we can
only pay attention to one of its running threads, this makes our lives
much easier when we try to figure out what the intention was.

I just thought of a situation in which a lot of threads make a huge
amount of sense when there's an observer/scheduler thread.  Think of a
tank division, potentially hundreds of vehicles and thousands of
people.  If we were to write software to simulate a battle, it seems to
me that one approach would be to give each battle unit its own thread,
and let them fight.  One thread to run the whole thing is just a
disgusting complication.  Of course, the problem is now how to make them
fight properly... maybe our little threads become too clever, we achieve
critical mass and we have to dump the thing.

So we introduce the Army General thread, which looks at what the other
threads are doing, thinks, and acts giving orders accordingly.  We give
intention to the system.  The smarter our Patton thread is, the more
intention we make explicit, the more sense things make.  We just made
the tank division (sort of) self-conscious... just like what really
happens, hmmmm...

Andres.




More information about the Squeak-dev mailing list