In article <e6catg$10ck$1@digitaldaemon.com>, Sean Kelly says...
>
>Dave wrote:
>> Sean Kelly wrote:
>>> Dave wrote:
>>>> Dejan Lekic wrote:
>>>>> Mr. (or Mrs.) jcc7, thank you - i have tried to find that post
>>>>> myself, but
>>>>> failed! :)
>>>>> Yes, that is a very nice thread, with many good ideas which followed.
>>>>> In short, the basic idea is to move thread support INTO the language.
>>>>> Best regards!
>>>>
>>>> I'd like to interject that, if more threading support is to be added to the language, it may be worthwhile to look into moving away from 'native threads' (including pthreads) into something more lightweight as the internal basis for D threading. Like the recently posted StackThreads library maybe(?). Many other languages (especially functional languages) are taking this approach - better performance, flexibility and portability.
>>>
>>> Yes and no.  With the number of processors on average systems increasing rapidly, there's definitely a place for kernel threads in today's world.  IMO Solaris handles threading fairly well as it automatically uses both user threads and kernel threads for the pthread API based on some system knowledge and influenced by some API parameters.  I like this better than cooperative user-level multithreading in most cases because it's easier to use and more flexible for the platform design, though it isn't quite so lightweight as mutexes and such must still be used.
>> 
>> I just had reason to take a look at the Solaris thread stuff the other day. Pretty cool.
>> 
>> So, I guess the challenge may be to try and provide flexible enough language mods. and (a reference) rt lib/compiler interface to accommodate the best for a given platform?
>
>I think so.  Personally, my main interest with new threading work is to provide something that avoids the need for direct of most synchronized blocks, thread construction, etc, as this stuff is notoriously difficult for even experienced programmers to get right.  In the past I've mentioned Herb Sutter's Concur project in relation to this, and there has been some discussion of related projects and technology as well. Were D to set its sights on concurrent programming I'd much prefer it be at this level rather than focusing on the traditional approach. However, I think a good interim solution (and to simplify implementing library support for this sort of thing) would be to expand the traditional interface somewhat, at least to include condvars and perhaps try-locks.  This can be done largely in library code (someone posted a condvar implementation a while back), but as it affects language semantics at least marginally I'd prefer it have some sort of official seal of approval.  For Ares I've been fairly careful so far to limit most of my changes to what I felt was readily identifiable as library code, as I don't want to muddy the waters about what is legal D syntax.
>

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.

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?