[Edu-sig] Re: Pygeo, platforms, wx and Tk

[Scott David Daniels]

Arthur wrote:
> Like most of us, I'm sure, almost anything I understand about programming I
> understand because I needed to understand it to solve a real problem. 

This is actually a learning style question.  I am personally only happy
working on a system when I "understand" the layer below it.  This is why
I dislike windows (the system I primarily use) so much, and why I have so
many issues with GUI programming -- I have a hard time letting go and
"letting it be magic."  Lucky for me I started with an ancient computer
(the LGP-30); there was something comforting about looking at discrete
components and boards of diodes with present and missing diodes.

 > ... it only at the point that they are solving *real* problems, even
 > if only for themselves, that they can get the sense of what it is to
 > program and be a programmer.

Actually, for me, the "real problem" is second.  I need a "real problem"
to test whether I really understand an idea, or only think I do.  I
often have to loop back around a time or two to "get" it.

>... Bottom line problem is that I am using threading without understanding
> threads. I'm guessing my answer is somewhere in getting down a level into
> the threads themselves, rather than trying to get away with only dealing at
> the level of the objects being threaded.  

If you have a concrete understanding of processes, try this idea for
threads:  the old idea of a process as a separate "machine" can be split
into two ideas: a resource allocation entity (for virtual memory, file
handles, security ...) which there is one of per process, and a
schedulable entity (which owns as little as possible) living inside a
process that determines what the CPU does next.  The latter of these
two is called a "thread of execution" (hence thread).

Multi-thread programming is simply multiprocess programming with all of
the safety protection between the separate processes turned off.
Sharing memory between threads is easy (they all live in the same
memory space), but dangerous, because the different threads can be
interwoven at the finest granularity available on the machine.  So,
sharing data that everyone reads is simple, but negotiating when a
write is seen by another thread requires planning. Usually this is
done by arranging that each thread plays in its own area, and writes
(often through queues) when the data is available for others to read.
A nasty complication to your intuition in threaded programming is
that things you thought were indivisible operations are so only from
the point of view of the thread performing the operation; often they
have parts that another thread can see in the half-completed view.

Python is lucky in that many python writes look like either:
     a) get a reference to a data structure (python object reference)
        and store it somewhere, an operation that _is_ indivisible.
or
     b) build a data structure which was formerly non-existent (and
        therefore not shared with anyone else) and store a single
        pointer to it, an operation that _is_ indivisible.

both of these work fine in a threaded environment.  However, operations
like list.reverse() have intermediate states.  So, for a list "data"
built like:
     data = range(1000000)
is examined by two threads, one of which is doing sum(data), and the
other of which is doing data.reverse(), the totals of the summing
thread can vary substantially.

-- 
-- Scott David Daniels
Scott.Daniels at Acm.Org