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

[Graham St Jack]

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