D has moved up to number 18!

[Dave]

In article <e6catg$10ck$1 at 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.