[dmd-concurrency] Vot de hekk is shared good for, anyway?

[Andrei Alexandrescu]

Graham St Jack wrote:
> Michel Fortin wrote:
>> Le 2010-01-10 à 22:47, Graham St Jack a écrit :
>>
>>   
>>> I'm happy with things being carefully wrapped and auto-magic. However, surely the message channel (or whatever it is called) object itself will have be shared (and its externally accessible methods synchronized), otherwise we are cheating. We have a object whose sole purpose in life is to be shared by multiple threads, so surely if anything is shared, this one has to be.
>>>
>>> If this is the case, then we need a mechanism to stop "shared" from leaking out into the whole code base.
>>>     
>>
>> When your browser requests a web page to a server, it sends messages and receives back replies. But it doesn't need the browser need to have a "shared" object with the server. Instead, you have a socket on each side and both get connected through the operating system's TCP/IP stack auto-magic.
>>
>> In the same way, a message-passing API, especially one that intends to go beyond threads, doesn't need and shouldn't expose any shared object. That doesn't mean the implementation won't use shared for thread-to-thread communications, but the user of the API shouldn't need to see that.
>>
>>
>>   
> I understand what you are saying, but your example is for inter-process 
> communications, and the shared objects you talk about are external to 
> the process, in non-D code.
> 
> I also understand that the messaging library is attempting to make 
> inter-thread, inter-process and inter-node communications all look the 
> same. I'm not sure this is a good idea, and I for one would like to have 
> a version of the messaging API that used blatantly shared objects for 
> good old-fashioned inter thread message passing. If such a thing doesn't 
> eventuate, I for one would like to be able to build one without having 
> to resort to back-door tricks.

The short answer is that there won't be an easy way to continue "good" 
(?) old-fashioned multithreaded programming in D with blatant (e.g. 
unchecked) sharing. That's a bad habit that we don't need and don't want 
to support.

Inter-thread and inter-process communication will obey different 
limitations, but they do have a common subset that we'll expose. That 
will help programmer in creating location-unaware concurrency.

> With communication between threads within a process, we are looking at 
> using the shared keyword to primarily indicate which objects are 
> potentially shared. I still think it is a cop-out to say "this shared 
> object is safe to use, so lets pretend it isn't shared". Sure, that 
> avoids the problems associated with the viral nature of the shared 
> keyword, but does nothing to help us understand how to get the design of 
> shared right.

I don't know what you mean. There's no pretense that shared objects are 
actually not shared, but I'm sure I'm missing a point.


Andrei