Dejan Lekic wrote:
> The only thing i really miss is better thread support. I have already proposed changes (about lock() keyword, and better thread synchronisation tuning), but you Mr. Bright did not respond. :) Some other guys did and they did like what i proposed.

Can you point me to the thread?

> *I have no words to express my apriciation for what you have done so far, and gave us all that for free.
> 
> Thank you Walter!*

You're welcome!

In article <e69jmh$bnq$1@digitaldaemon.com>, Walter Bright says...
>
>Dejan Lekic wrote:
>> The only thing i really miss is better thread support. I have already proposed changes (about lock() keyword, and better thread synchronisation tuning), but you Mr. Bright did not respond. :) Some other guys did and they did like what i proposed.
>
>Can you point me to the thread?

I guessing it's this: http://www.digitalmars.com/d/archives/digitalmars/D/35240.html

jcc7

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!

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.

IMHO, it be best to either a) release v1.0 w/ thread support as-is and redesign it for v2 or b) delay v1 until it has any improvements Walter may deem worthy, because I can only see MT as becoming hugely important in the next couple of years.

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.

> IMHO, it be best to either a) release v1.0 w/ thread support as-is and redesign it for v2 or b) delay v1 until it has any improvements Walter may deem worthy, because I can only see MT as becoming hugely important in the next couple of years.

Definately.


Sean

Dave, i have thought of your StackThreads library too. IMHO there is no need for such thing, for average D programmer. Sure, i could be wrong. :) - I have no time to talk about reasons as i rush to go to work now. :)

Kind regards - btw. i like StackThreads!

In article <e6abkk$1i2d$1@digitaldaemon.com>, Dejan Lekic says...
>
>
>Mr. (or Mrs.) jcc7, thank you - i have tried to find that post myself, but
>failed! :)

I'm a guy. Some people call me Justin, but jcc7 is what I go by around here. ;)

You're welcome. I found it quickly with the search box at http://www.digitalmars.com/d/index.html

jcc7

Dejan Lekic wrote:
> Dave, i have thought of your StackThreads library too. IMHO there is no need
> for such thing, for average D programmer. Sure, i could be wrong. :) - I
> have no time to talk about reasons as i rush to go to work now. :)
> 
> Kind regards - btw. i like StackThreads!
> 

I wish I could take credit for it, but I can't :) A Mr. Lysenko wrote it (credits are here): http://assertfalse.com/ <g>

Frankly I haven't tried them out, but I think the idea has merit. I'll defer to the real experts on threading in this group as to the best way to approach things.

The reason I brought it up is: if somewhat of a re-design is done, it *may* make sense to look into basing it on something other than kernel threads - but then again maybe not (as Sean describes in a previous post).

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?

>> IMHO, it be best to either a) release v1.0 w/ thread support as-is and redesign it for v2 or b) delay v1 until it has any improvements Walter may deem worthy, because I can only see MT as becoming hugely important in the next couple of years.
> 
> Definately.
> 
> 
> Sean

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.


Sean