Re: Patch for fields of `struct buffer'

[Stephen J. Turnbull]

Lennart Borgman writes:
 > On Tue, Feb 1, 2011 at 1:10 PM, Stephen J. Turnbull <address@hidden> wrote:
 > > Daniel Colascione writes:
 > >
 > >  > The world is increasingly moving toward parallel processing,
 > >
 > > Since when does parallel processing == threads?
 > 
 > I am a computer illiterate sometimes. Could you give us some hints
 > about the current status?

Well, that's actually what I was asking Daniel.  I'm not sure how
illiterate you think you are, so please try not to be insulted if it's
all too basic.

By *definition*, both threads and processes are ways of multitasking
which allow various forms of "parallel processing", such as multi-CPU
processing and time-slicing.  There are other forms of parallel
processing, such as GPUs on the video card and DMA for I/O, but these
are rather specialized.

In *theory*, both threads and processes should be capable of being
distributed across processors, and AFAIK they both work pretty well in
practice each with its advantages and disadvantages.

The specific difference between threads and processes is that threads
share all resources of a single process *except* the instruction
counter, and thus can communicate with each other with maximum
efficiency.  Processes do not share resources with each other, and
thus it is impossible (absent an OS or hardware bug) for one process
to stomp on another's resources, thus providing maximum safety for
each task.  In fact there are intermediate possibilities, for example
shared memory allows two separate processes to access the same
memory.  Any variables stored in that area are efficiently
communicated between the processes.

Now, in practice threads require protection from each other, just as
processes do when accessing disk (thus the infamous "stale lock"
problem in CVS and Subversion, which many workflows for dVCSes can
reduce to almost zero).  If you allocate a resource on the heap (often
called "consing" in Lisp, and is commonly extended to resources other
than Lisp conses), then in theory only a thread hold a pointer to it
can access it, thus providing some protection.  However, a wild
pointer "for (p = memory; ; p++) { write(stuff,p); }" can trash
another thread's private resources, while this can't happen with
processes.

The problem with threads as I see it, and I believe this is why
Richard and Guido express pessimism too, is that Lisp objects tend to
get all linked together.  Tasks that follow the links and mutate the
objects are likely to interfere with each other, but that is a very
common pattern in dynamic languages.  In Python, this is handled with
the GIL, or global interpreter lock.[1]  In many circumstances, a thread
must grab that lock, excluding all other threads from running.  This
also is somewhat expensive in terms of CPU AIUI.  Many proposals have
been made to remove the GIL from Python, but (so far) they all fall
down because it turns out that keeping track of lots of "local" locks
is either very expensive, or deadlock-prone.  (The "STM" that I
mentioned in connection with Haskell and Simon Peyton-Jones is more or
less a technique for automatically managing "local" locks, and has
been applied successfully in some projects.)

Of course, processes also involve high costs, specifically the cost of
context switching when interrupting one process and starting another,
and the cost of copying shared data back and forth between the
cooperating processes.

But on balance my intuition (FWIW, probably not much in this case :-)
is that threads are fundamentally a low-level, performance-oriented
implementation of the high-level abstraction "concurrent task", and
that there's a severe impedence mismatch with Lisp, especially Emacs
Lisp.

Footnotes: 
[1]  I refer here to the mainline Python written in C.  Jython and
IronPython are based on different virtual machines which don't have
GILs.