Re: [Nomen-dev] A radical idea: a non-threaded language

[Denis <ji...@re...>]

Hi Brian

Still coming with more revolutionary ideas! :-)

On Tuesday, March 26, 2002, at 11:33  pm, Brian Hurt wrote:

> I was ranting at my brother yesterday about threads, and general 
> why unix
> is better than windows sort of verbage.  I'll skip the unix-
> vr.s-windows
> comments as irrelevent, and just focus on threads.  My main points 
> were:
>
> 1) Threads encourage hard to find, hard to reproduce bugs- deadlocks,
> resource starvation, race conditions, etc.  Worse yet, the logic behind
> what is and isn't safe is subtle, see:
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

IMO threads are a low-level facility, like raw access to console 
input etc. They are difficult to use properly.

>
> 2) Threads are, for most uses they are put to these days, 
> inefficient or
> simply to make up for poor design.  What are the three most common 
> uses of
> threads?
>
> 	A) Handle inputs/outputs from multiple streams simultaneously- web
> servers, print spoolers, etc.  This is better handled by 
> asyncronous I/O
> routines (poll, select, aio, etc).  Actually, this is best handled by
> fork() and copy on write pages, but that's kinda OS dependent.

??
I would use threads if I'd want to do asynchronised I/O... Wouldn't 
you? Ok fork() is an alternative, but I don't see async i/o as an 
alternative. I must be missing the point.

>
> 	B) Split a CPU intensive computation across multiple CPUs.  OK,
> This is a legitimate usage of threads- but I think that using 
> fork() and
> COW pages would work about as well.  Better yet, use a network protocol
> like MPI (IIRC) and allow you to split your computation across multiple
> computers (Beowulf cluster, anyone?).

For this case it would be nice to have a construct to run several 
pieces of computation in parallel, and send/receive data with the 
forks. I am thinking of a pipe- or message-based protocol.

>
> 	C) Maintain the illusion of responiveness in a slow GUI.  This
> implies both bad library design and bad code architecture.  The 
> fact that
> the MFC is rife with these problems doesn't make it acceptable.

Mmh... What about BeOS? It doesn't seem to me that the heavy 
multi-threading is in any way there for 'bad library design and bad 
code architecture'. The mere fact that threads helped to improve 
Windows performance, /despite/ the shortcomings, rather supports 
the use of threads in GUIs.
BTW, Java uses threads in the GUI frameworks but the programmer 
don't deal with them... unless he implements his own threads, in 
which case it becomes a mess.

>
> So the idea occurred to me- do we have to have threads in the 
> language at
> all?

I don't want threads. I want parallelism.

>
> Wait a minute- before you start pelting me with those rotten 
> vegitables,
> think about it.  Most multithreaded code is bad code- do we want to be
> encouraging the production of bad code?
>
> The other alternative is to do something to make threads safer.  
> There are
> two possible ideas here:
>
> 1) Have the virtual machine use green threads, but don't support kernel
> threads.  This gives us a level of control, but fails the primary
> *legitimate* purpose of multithreading- using multiple CPUs.  This 
> could
> be offset using fork and various RPC protocols (CORBA, COM, etc).

I would prefer to have kernel threads (using multiple CPUs), but 
hidden from the programmer. In a first time we could implement them 
with green threads to be sure we are doing the things right.

>
> 2) Compiler-added locking.  Using algorithms similiar to those used by
> GCs, it's possible to determine what objects are accessible from 
> multiple
> threads.  You would then have multiple different "memory regions"- each
> thread has a memory region of objects only it can access, and a shared
> region of objects multiple threads can reach.  When the thread 
> follows a
> reference into the common area, it has to obtain a lock.  
> Determining the
> minimum number of locks necessary would be tricky.  Avoiding deadlocks
> would be trickier yet.
>
> Hmm.  Actually, choice #2 has some potiential.  I shall have to think
> about it some more.

Choice #2 seems interesting, I am sure there are valid abstractions 
out there to do what threads do with more control. If following 
memory references allows such an abstraction to be implemented, I 
am all for it.

-- Denis.

>
> Brian
>