View mode: basic / threaded / horizontal-split · Log in · Help
December 11, 2006
Concurrency
Given that the world of PC are heading down the path of muti-cpus:

What features does D supply to take advantage of concurrency, over an 
above what can be accomplished though C++ today?

How could the language be improved to be better at concurrency problems 
then other languages?

(You'll not that I left out the word threading as that is only one form 
of concurrency programming).

-
I'm just thinking that, perhaps if concurrency is handled well enough in 
D, it can catch the wave of parallel programming that is on the horizon.
December 11, 2006
Re: Concurrency
janderson wrote:
> Given that the world of PC are heading down the path of muti-cpus:
> 
> What features does D supply to take advantage of concurrency, over an 
> above what can be accomplished though C++ today?

A definition of 'volatile' that works.  I'd say more, but "can be 
accomplished" is a pretty broad category.

> How could the language be improved to be better at concurrency problems 
> then other languages?

Improved support for advanced concurrency features.  I've seen a test 
copy of CSP for D, which is a nice start.  And futures wouldn't be very 
difficult to write in library code.  Really, I think it comes down to 
finding simpler ways to break up the traditionally sequential nature of 
imperative code.  A good bit of work still needs to be done here even at 
the research level, as I haven't seen any solution yet that's without 
problems.  Oh, software transactional memory might be an interesting 
experiment as well.

> I'm just thinking that, perhaps if concurrency is handled well enough in 
> D, it can catch the wave of parallel programming that is on the horizon.

I'd be surprised if it didn't.


Sean
December 12, 2006
Re: Concurrency
janderson Wrote:

> Given that the world of PC are heading down the path of muti-cpus:
> 
> What features does D supply to take advantage of concurrency, over an 
> above what can be accomplished though C++ today?
> 
> How could the language be improved to be better at concurrency problems 
> then other languages?
> 
> (You'll not that I left out the word threading as that is only one form 
> of concurrency programming).
> 
> -
> I'm just thinking that, perhaps if concurrency is handled well enough in 
> D, it can catch the wave of parallel programming that is on the horizon.

D should be the language of choice when it comes to concurrency. This the window of opportunity for D. Since none of the currently "popular" languages speaks concurrency fluently.
December 13, 2006
Re: Concurrency
vtp (vanh@dslextreme.com) 	2006/12/12 17:53
>>janderson Wrote:
>> I'm just thinking that, perhaps if concurrency is handled well enough in
>> D, it can catch the wave of parallel programming that is on the horizon.
>D should be the language of choice when it comes to concurrency. This the window
of opportunity for D. Since none of the currently "popular" languages
>speaks concurrency fluently.

That's the correct timeperiod sure, but the problem is that the 'concurrency'
topic is far from being settled, there are so many ways to treat it: threading and
locks (don't compose), STM (still a research topic and not a complete solution: it
cannot handle side-effect), like in the Concur project active object waiting for
future events (the mapping of "future thread" to real thread doesn't seem obvious
to me to get good performances), CSP, etc.

renoX
December 14, 2006
Re: Concurrency
janderson wrote:
> Given that the world of PC are heading down the path of muti-cpus:
> 
> What features does D supply to take advantage of concurrency, over an 
> above what can be accomplished though C++ today?
> 
> How could the language be improved to be better at concurrency problems 
> then other languages?
> 
> (You'll not that I left out the word threading as that is only one form 
> of concurrency programming).
> 
> -
> I'm just thinking that, perhaps if concurrency is handled well enough in 
> D, it can catch the wave of parallel programming that is on the horizon.

I agree that D should have more support for concurrency. Putting some 
sensible support into the language is FAR better than trying to do it 
all with libraries.
December 14, 2006
Re: Concurrency
Graham St Jack wrote:
> janderson wrote:
>> Given that the world of PC are heading down the path of muti-cpus:
>>
>> What features does D supply to take advantage of concurrency, over an 
>> above what can be accomplished though C++ today?
>>
>> How could the language be improved to be better at concurrency 
>> problems then other languages?
>>
>> (You'll not that I left out the word threading as that is only one 
>> form of concurrency programming).
>>
>> -
>> I'm just thinking that, perhaps if concurrency is handled well enough 
>> in D, it can catch the wave of parallel programming that is on the 
>> horizon.
> 
> I agree that D should have more support for concurrency. Putting some 
> sensible support into the language is FAR better than trying to do it 
> all with libraries.

I think the problem is that this is a developing field, and language 
additions tend to be somewhat permanent.  Sutter's futures, for example, 
could benefit from a bit of language support (the active object part), 
but I'm not convinced the idea is quite "there" yet.  And something like 
what's in Cilk may be more mature but seems a bit too much for D. 
Better language support for concurrency will have to be a 2.0 thing, if 
only to allow more time for experimentation in library code.


Sean
December 15, 2006
Re: Concurrency
Sean Kelly wrote:
> Graham St Jack wrote:
>> janderson wrote:
>>> Given that the world of PC are heading down the path of muti-cpus:
>>>
>>> What features does D supply to take advantage of concurrency, over an 
>>> above what can be accomplished though C++ today?
>>>
>>> How could the language be improved to be better at concurrency 
>>> problems then other languages?
>>>
>>> (You'll not that I left out the word threading as that is only one 
>>> form of concurrency programming).
>>>
>>> -
>>> I'm just thinking that, perhaps if concurrency is handled well enough 
>>> in D, it can catch the wave of parallel programming that is on the 
>>> horizon.
>>
>> I agree that D should have more support for concurrency. Putting some 
>> sensible support into the language is FAR better than trying to do it 
>> all with libraries.
> 
> I think the problem is that this is a developing field, and language 
> additions tend to be somewhat permanent.  Sutter's futures, for example, 
> could benefit from a bit of language support (the active object part), 
> but I'm not convinced the idea is quite "there" yet.  And something like 
> what's in Cilk may be more mature but seems a bit too much for D. Better 
> language support for concurrency will have to be a 2.0 thing, if only to 
> allow more time for experimentation in library code.
> 
> 
> Sean

This may be the case, however it would be worth investigating other 
languages (in particular ones designed around concurrency).  Maybe the 
solution will be a library with D simply providing support to make the 
library easier to use then it otherwise would be.  I'm not sure. 
Something I think needs to be discussed.

What are the best and newest parallel languages out there?   What are 
the most difficult parts to solve?

What are the best libraries?  What are the hardest parts to use in those 
libraries?

I'm particularly interested if the difficult parts of lockless 
programming supported in some form.

-Joel
December 15, 2006
Re: Concurrency
janderson wrote:
> Sean Kelly wrote:
>> Graham St Jack wrote:
>>> janderson wrote:
>>>> Given that the world of PC are heading down the path of muti-cpus:
>>>>
>>>> What features does D supply to take advantage of concurrency, over 
>>>> an above what can be accomplished though C++ today?
>>>>
>>>> How could the language be improved to be better at concurrency 
>>>> problems then other languages?
>>>>
>>>> (You'll not that I left out the word threading as that is only one 
>>>> form of concurrency programming).
>>>>
>>>> -
>>>> I'm just thinking that, perhaps if concurrency is handled well 
>>>> enough in D, it can catch the wave of parallel programming that is 
>>>> on the horizon.
>>>
>>> I agree that D should have more support for concurrency. Putting some 
>>> sensible support into the language is FAR better than trying to do it 
>>> all with libraries.
>>
>> I think the problem is that this is a developing field, and language 
>> additions tend to be somewhat permanent.  Sutter's futures, for 
>> example, could benefit from a bit of language support (the active 
>> object part), but I'm not convinced the idea is quite "there" yet.  
>> And something like what's in Cilk may be more mature but seems a bit 
>> too much for D. Better language support for concurrency will have to 
>> be a 2.0 thing, if only to allow more time for experimentation in 
>> library code.
>>
>>
>> Sean
> 
> This may be the case, however it would be worth investigating other 
> languages (in particular ones designed around concurrency).  Maybe the 
> solution will be a library with D simply providing support to make the 
> library easier to use then it otherwise would be.  I'm not sure. 
> Something I think needs to be discussed.
> 
> What are the best and newest parallel languages out there?   What are 
> the most difficult parts to solve?

Very quickly (because I'm exhausted and on my way to bed), I think CSP 
is the right idea but falls apart in its "sequential" aspect.  Ideally, 
any concurrent programming approach should apply equally to traditional 
and to distributed systems in that it shouldn't matter how or where 
operations are performed so long as they're performed and the program 
state remains coherent.  ORB architectures (CORBA, DCOM) work along 
these lines as a library approach, but they put the burden of 
concurrency on the user much like mutexes and such do for traditional 
multithreaded programming.  Also, I think a process algebra would be 
ideal for any such solution to guarantee that a system built on the 
technique was provable.  And while there does appear to be some current 
work in the area, who knows how long it will take to bear fruit.

As for parallel languages... I've already mentioned Cilk and think it 
appears to be pretty decent.  Can't think of any others offhand, though 
C# has actually proved to be a good platform for experimental language 
features, because the language is actually extensible in some ways.  In 
fact, it already has a test version of Sutter's active objects and 
futures available as well as software-transactional memory, both with 
some degree of "language support."

> What are the best libraries?  What are the hardest parts to use in those 
> libraries?

ACE is probably the best for C++, though I've used it only sparingly. 
Not sure about other languages.

> I'm particularly interested if the difficult parts of lockless 
> programming supported in some form.

I'm less interested in details than in the high-level design.  If a 
library uses lock-free then great, and if it uses something else that's 
fine too, just as long as it scales appropriately, offers the 
appropriate progress guarantees, etc.  For example, CSP may be 
implemented using mutexes, lock-free, etc, but this is all invisible to 
the user.  He simply knows that tasks are being issued and completed 
concurrently, and that's all that matters.


Sean
Top | Discussion index | About this forum | D home