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

[Andrei Alexandrescu]

You are describing message passing, which in D is virtually built in - 
you don't need to define your own Queue. There will be a simple send and 
receive mechanism that I will describe in the next draft.

Andrei

Graham St Jack wrote:
> Andrei Alexandrescu wrote:
>>> 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.
> Almost all my multi-threaded code uses a synchronized queue template for 
> inter-thread communication, and I always transfer immutable or by-value 
> data.
> 
> It looks like this:
> 
> Producer Thread ---(add)---> Queue <---(remove)---- Consumer Thread.
> 
> The Queue is shared between the two threads, and all of its public 
> methods are synchronized. The Queue is shared, but the messages are 
> immutable.
> 
> My assertion is that Queue (and any other classes like it) should be 
> marked as "shared", so we clearly understand where our threads are in 
> contact, and so the compiler can help us keep to the straight and narrow.
> 
> My question is "what are we going to do with the language to stop shared 
> from infecting the entire application", which is what always happened to 
> me in the past whenever I attempted to define Queue to be a shared class.
> 
>>
>>
>> Andrei
>> _______________________________________________
>> dmd-concurrency mailing list
>> dmd-concurrency at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
> 
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency