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

[Michel Fortin]

Le 2010-01-11 à 18:10, Graham St Jack a écrit :

> Michel Fortin wrote:
>> 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. 

It doesn't change a thing. Passing objects by reference should be an optimization, not a requirement. It'd be pretty dumb if it wasn't possible between thread, I agree. But we don't need to make the user aware of it.


> 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.

You will be capable of making your own communication mechanisms using shared. If you can't, it'd mean that shared is pretty dysfunctional.


> 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.

If you're talking about immutable, it was Walter's decision to keep the type system simpler by having immutable and shared-immutable be the same. And I don't think reopening that debate will lead to anything.

If you're talking about the message passing API... well I'm not the one designing it but if I were the internal implementation for thread-to-thread communication would use shared, but the user-visible parts (the API) wouldn't. For instance, you could have this struct:

	struct MessageDispatcher {
		private shared MessageQueue messageQueue;
		
		void send(string[] message) {
			synchronized (messageQueue) {
				messageQueue.add(message);
			}
		}

		string receive() {
			synchronized (messageQueue) {
				while (messageQueue.empty)
					messageQueue.wait();
				return messageQueue.get();
			}
		}
	}

And you would use the endpoint like this:

	void main() {
		MessageDispatcher dispatcher = createOneSomehow();
		span(&threadFunc, endpoint); // endpoint passed *by copy*
		endpoint.send("hello");
	}

	void threadFunc(MessageDispatcher dispatcher) {
		string message = dispatcher.receive(); // blocking
		// ... use message
	}

I'm not sure how putting "shared" in the user's code would help anything here. Sure, if I wasn't passing an immutable string it wouldn't work, but that's just a crude example. I'd expect the message passing API to accept anything as a message. If the message is neither immutable nor shared, then the message passing API should make a copy; if it is immutable or shared, then it can and should be passed as-is to the other thread. Does that make sense?

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/