[dmd-concurrency] Defining shared delegates

[Robert Jacques]

On Tue, 19 Jan 2010 17:47:54 -0500, Andrei Alexandrescu  
<andrei at erdani.com> wrote:

> Robert Jacques wrote:
>> On Tue, 19 Jan 2010 15:20:07 -0500, Andrei Alexandrescu  
>> <andrei at erdani.com> wrote:
>>> One suggestion about shared delegates: should we take the executive  
>>> decision to not define them at all? There's nothing you can do with  
>>> delegates that you can't do with classes. Although generally delegates  
>>> do justify their existence because they're more comfy than e.g. local  
>>> classes, it doesn't strike me as obvious we'll need comparable  
>>> convenience when dealing with shared classes.
>>>
>>> Andrei
>>  I can express pretty much all of my parallel research algorithms  
>> safely using const delegates, I can't express any of them safely using  
>> a shared class: I'd have to cast/cowboy everything.
>
> I don't understand. Really a delegate is a class and a class is a  
> (multi-faceted) delegate. So if you can do things one way, you should be  
> able to do them the other way too.

Okay, my statement wasn't about can I do it. It was about can I do it  
safely and easily. And, in part exploiting the different constraints  
between shared and const, which is an orthogonal concept. But there was a  
reason OpenMP went to the extreme of adding extra compiler directives,  
instead of using a function that takes a const interface, which users  
would implement with nested classes, etc.

>> I'd think this will be true of most OpenMP / data parallel algorithms.  
>> And I think not supporting data parallel algorithms cleanly would be  
>> just as bad as not supporting clean message passing.
>
> I'm afraid there is no time for addressing data parallel computing. We  
> simply don't have the resources. This may be a bummer, but it's the  
> reality. One other real fact that is also a bummer is that the best way  
> to add a great contribution to the language right now is to improve on  
> the drafts that I'm sending, as opposed to discussing new, tall-order  
> ideas. For draft 5 I only got three "act-on" comments, all from Steve.
>
> It will be great to discuss new and large-effort ideas once the book  
> goes out. Can't wait. Until then, if you find a comma in the wrong font,  
> let me know.
>
>
> Andrei

This worries me a lot, because it feels like D will freeze after TDPL is  
release. I understand that a lot of implementation won't be there, or it  
may be buggy, but I'd really hate to have the core language simply not  
support something.

As for draft comments, spawn shouldn't be returning a thread id, it should  
be returning a message box id, because message passing won't be limited to  
OS threads, so your examples shouldn't imply that it is. You should also  
have an example using a separately created mailbox and an CSP style  
alternative example where multiple mailboxes are waited upon.

As for data parallel computing in general, there are people working on  
implementations, but I don't know how tight TDPL deadline is. But right  
now, these implementations are completely unsafe. Some brainstorming and  
code reviews lead to the idea that using a const/shared/immutable delegate  
would allow for a mostly safe set of library functions. And it seemed  
simple to define the taking the address of a const or shared member  
function to generate a const or shared delegate; which would make the  
library interface much cleaner. Anonymous shared/const delegate can come  
later.