Re: [Chicken-users] An alternative thread system?

[Ivan Raikov]

  Well, the design of such an alternative library should be guided by
the users' needs. What are the usage scenarios? What aspects of those
scenarios cannot be met by the standard Unix process model?
Shared-memory concurrency is a complicated issue, and the design of
such a library should be undertaken lightly, unless you are absolutely
certain that your application cannot be implemented with forks and
pipes. 

  Remember that threads were popularized by the big Unix vendors in
the late 1980s and early 1990s, when process forking on a workstation
was computationally expensive, because most commercial Unices would
copy the entire process context upon forking. The quick and easy
solution was to introduce shared-memory processes ("threads"), which
did not require expensive context copying, and market them as the Next
Big Thing, while disregarding the incredible complexity of designing
correct shared-memory concurrent systems. The inertia of the early
1990s spilled over to Java and more recent programming language
environments, and I suspect has been a leading cause for defective
software designs.

  Today, modern kernel implementations such as Linux do not copy the
entire process context. When the kernel creates a copy of the process,
the memory blocks that might be modified by either the process or its
copy are marked copy-on-write. If one process tries to modify the
memory, the kernel intercepts the request and copies the memory so
that changes in one process's memory are not visible to the
other. Linux also uses one kernel thread to manage several user
threads, and employs other optimizations that make forking in the
common case about as cheap as creating a thread, but with none of the
problems caused by user-space threading libraries.

   Threads are difficult to debug, because very subtle timing
differences could cause a bug to manifest itself with very low
probability. And when you step through your program under a debugger,
everything would seem perfectly synchronized, because of the long
delay between program steps. By comparison, if you have two Unix
processes that exchange messages over a pipe, you can construct the
state machine that manages the communication so that it is correct by
design and is invariant of message arrival time. So consider simpler
designs and do not rely so heavily on threads.


   -Ivan



Jörg "F. Wittenberger" <address@hidden> writes:

> Hi all,
>
> I must admit that I'm not happy with the deletion of a single #\i from
> the chicken source incurring a lengthy discussion about the usefulness
> of the containing definition.  I feel this discussion is rather short
> sighted.  If one was to drop thread-terminate!, one should fix more of
> those "ill-conceived" concepts in SRFI-18 and drop the abandoned mutex
> (for instance) state too, thereby avoiding mutex-lock! throwing useless
> exceptions and remove quite a lot of (then useless) code from the whole
> thread system.
>
> But this will lead to a complete alternative thread system.
>
> Once this one is useful - and that includes IMHO the possibility to
> forcefully terminate a thread in some, here undefined, way - it should
> become yet another SRFI and eventually SRFI-18 ought to be depreciated
> entirely.
>
> Still - for a practical Scheme system - we would probably need an egg to
> load if one wants to run existing code, which was written to the SRFI-18
> API.
>
> Hereby I'd like to ask you for proposals, how this alternative could
> look alike.  I'm ready to participate in such a discussion (in contrast
> to my string objection to simply drop thread-terminate!).