Threads [Was: Re: D has moved up to number 18!]

[Georg Wrede]

Dave wrote:

> I think condvars and try-locks would be great (semaphores too)... I'm
> wondering if it would make sense for support of threads and related
> to just be added directly to the language? New keywords, a built-in
> thread type and all? Or something like building at least rudimentary
> OpenMP type functionality into the language?
> 
> Ideally, I'd like to see thread/MP support such that it would
> eliminate much of the productivity advantages that languages that are
> supposed to be able to 'auto-parallelize' loops may have (like Sun's
> new 'Fortress').
> 
> For D these things would still be explicit, like it should be for a
> GP/systems orientated language, and would help keep the compiler
> implementation effort reasonable as well. I can see support like that
> lasting well into the next decade, until compilers or runtimes are
> truly smart-enough to do a really good job at auto-parallelization
> and such. That is, if the syntax and semantics can be made straight
> forward enough that better control is worth a bit more development
> time for the general case, then I think a statically compiled D could
> stay competitive in this area.

[Sorry for vague terminology, etc., I've been up all night. :-/ ]

I'd really like to have both cooperative threads _and_ thread and/or MP 
support.

Of these two, I think cooperative threads is the bigger priority. It is 
also easier to implement (especially in a portable manner), and really 
it would behoove us to have a proper implementation in Phobos asap, and 
not only until D1.0! Especially when we have some very promising 
candidates already.

---

As an aside, I can imagine quite a few applications where I'd use _both_ 
cooperative threads and preemptive threads.

The parts that get used by cooperative threads only, would not need 
critical sections and thus be easy to write. Also, why not use them 
wherever they suffice. Only those places where both coop and preemptive 
manipulate something need critical sections and such.

So, in such an application we could strive towards a clean separation of 
the tasks that can be done with each of the two (or more) main 
("mutually pre-emptive") threads. Each could then "contain" possibly a 
number of cooperative threads -- without the whole thing becoming hard 
to manage.

What comes to mind are serious games, especially multiplayer, process 
automation (yes I'm at it right now!), robotics (even toy robotics ;-) 
), simulations, and real-time data streams control and manipulation.

Or a heavy-duty word processor, programming environment, database GUI, 
or 3D model designer. (In those, the UI could be done with cooperative 
threads. Another thread (possibly even containing cooperative 
("sub")threads) could then incrementally refine the rendition of 
objects, restructure data in the background, make "smarter" incremental 
temporary backups, etc.)

---

Being tired right now, I can't figure out which (if any) changes to the 
D language, would be unavoidable to get both of these not only useful -- 
but smooth, elegant, obvious and natural to use?