Concurrency

[Sean Kelly]

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