[9fans] Channel casting

[9fans] Channel casting

[northern snowfall]

Afternoon, all;
    Regarding channels in threads and procs, is a
given channel multicast or unicast? By that, I mean,
say I have multiple threads in a blocking recv() from
a Channel. The service thread reads a request off the
Channel, then, wants to send an appropriate response
to the sender. If the server thread then send()s on
the Channel while the multiple client threads are
recv()ing, will the correct client thread receive
the reply? Will they all receive the reply? What is
the strategy for this issue.
Don

Re: [9fans] Channel casting

[Russ Cox]

unicast.

For the case you describe, the client typically
sends a (request, return-channel) pair and
then recvs from the return channel, which is
private to that client.

Russ

Re: [9fans] Channel casting

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 23 bytes --]

and a thing of beauty

[-- Attachment #2: Type: message/rfc822, Size: 1790 bytes --]

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Channel casting
Date: Mon, 19 May 2003 18:24:49 -0400
Message-ID: <3100726675a9ffcb9f2eefc78956dba1@plan9.bell-labs.com>

unicast.

For the case you describe, the client typically
sends a (request, return-channel) pair and
then recvs from the return channel, which is
private to that client.

Russ

Re: [9fans] Channel casting

[northern snowfall]

>
>
>For the case you describe, the client typically
>sends a (request, return-channel) pair and
>then recvs from the return channel, which is
>private to that client.
>
Ah, okay. Let me make sure I understand this.
First, client C creates its own Channel.

Second, C generates the request structure
suitable to the server thread, including the private
Channel as a member.

Third, C sends the request structure to to the
server S via the public Channel.

Fourth, S retrieves said req, manifests the proper
response structure, then sends the response back on
C's private Channel.

Finally, C receives the response on the private channel,
then, optionally closes the private chan.

Correct?

>

Re: [9fans] Channel casting

[Russ Cox]

> Correct?

Yes.  In Limbo, here's an echo server:

	srvchan := chan of (int, chan of int);
	for(;;){
		(n, c) := <-srvchan;
		c <-= n;
	}

And some clients:

	echothread(srvchan: chan of (int, chan of int))
	{
		c := chan of int;
		for(i:=0;; i++){
			srvchan <-= (i, c);
			j := <-c;
			sys->print("sent %d, got %d\n", i, j);
		}
	}

	spawn echothread(srvchan);
	spawn echothread(srvchan);
	spawn echothread(srvchan);
	spawn echothread(srvchan);

or something like that.  You can do the same with libthread,
but everything is uglier in libthread.

Russ

Re: [9fans] Channel casting

[northern snowfall]

Great, thanks!
Don

Re: [9fans] Channel casting

[rog]

> For the case you describe, the client typically
> sends a (request, return-channel) pair and
> then recvs from the return channel, which is
> private to that client.

note that if clients adhere correctly to protocol, then it's not
strictly necessary to allocate a new channel each time.

to modify russ's examples:

an echo server:
	srvchan := chan of int;
	srvreplychan := chan of int;
	for(;;){
		n := <-srvchan;
		srvreplychan <-= n;
	}

	echothread(srvchan, replychan: chan of int)
	{
		for(i:=0;; i++){
			srvchan <-= i;
			j := <-replychan;
			sys->print("sent %d, got %d\n", i, j);
		}
	}

	spawn echothread(srvchan, srvreplychan);
	spawn echothread(srvchan, srvreplychan);
	spawn echothread(srvchan, srvreplychan);
	spawn echothread(srvchan, srvreplychan);

since we're using synchronous (unbuffered) channels, and clients
always write, then read, the server is guaranteed to be writing back
to the same client.

sometimes this makes things simpler; other times, sending a reply
channel makes more sense (particularly when the kind of reply might
depend on the particular request).

  cheers,
    rog.

Re: [9fans] Channel casting

[Russ Cox]

> sometimes this makes things simpler; other times, sending a reply
> channel makes more sense (particularly when the kind of reply might
> depend on the particular request).

also when the timing of the reply might depend on the particular request.

Re: [9fans] Channel casting

[northern snowfall]

>
>
>since we're using synchronous (unbuffered) channels, and clients
>always write, then read, the server is guaranteed to be writing back
>to the same client.
>

What I was mainly worried about was timing.
If one thread sends a request, but, another
thread preempts that first thread's call to
recv, wont the second thread receive the
server thread's response?

>

Re: [9fans] Channel casting

[Russ Cox]

> What I was mainly worried about was timing.
> If one thread sends a request, but, another
> thread preempts that first thread's call to
> recv, wont the second thread receive the
> server thread's response?

The way I wrote the server it's only ever handling
one request at a time, which means that only the
thread who sent that request has finished sending.

You're right that if the server handles multiple
requests at a time then you need a reply channel.

Russ

Re: [9fans] Channel casting

[rog]

> What I was mainly worried about was timing.
> If one thread sends a request, but, another
> thread preempts that first thread's call to
> recv, wont the second thread receive the
> server thread's response?

there's no problem if the server is single threaded and only serves
one request at a time.

the problem you speak of can only happen if two threads are both
trying to recv at the same time, but that can't happen if clients
always write before they read (and the channels are synchronous), as
all the clients will queue up to write to request, and the server lets
them through one at a time, sending the reply back before it lets the
next one in.

try modelling it in spin...

Re: [9fans] Channel casting

[okamoto]

> always write before they read (and the channels are synchronous), as
                                                                       ^^^^^^^^^^^^^^^^^^^^

We experienced it's not so easy to keep this.  ?

Kenji

Re: [9fans] Channel casting

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 9 bytes --]

how so?

[-- Attachment #2: Type: message/rfc822, Size: 1676 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Channel casting
Date: Thu, 22 May 2003 10:09:34 +0900
Message-ID: <964b87494cb2caf04beb3f2637745a08@granite.cias.osakafu-u.ac.jp>

> always write before they read (and the channels are synchronous), as
                                                                       ^^^^^^^^^^^^^^^^^^^^

We experienced it's not so easy to keep this.  ?

Kenji

Re: [9fans] Channel casting

[okamoto]

> how so?

Actually, I couldn't poit out what is really the problem in our marsv.
It looks like we have no problem, however, sometime it hanged up,
or depends on the speed of CPU etc.   Then, I decided to use buffered
channel to avoid this...   I know it's not a very right solution, however,
we couldn't live with this buffered channel.   If you want to see our
problem, you can find out it from our sources of marsv where we used
a buffered channel, which I didn't want of course.

Kenji

Re: [9fans] Channel casting

[Russ Cox]

> Actually, I couldn't poit out what is really the problem in our marsv.
> It looks like we have no problem, however, sometime it hanged up,
> or depends on the speed of CPU etc.   Then, I decided to use buffered
> channel to avoid this...   I know it's not a very right solution, however,
> we couldn't live with this buffered channel.   If you want to see our
> problem, you can find out it from our sources of marsv where we used
> a buffered channel, which I didn't want of course.

It sounds like you have a simple deadlock.  If you put
the unbuffered channel back and then wait for it to
hang, you can inspect the process with

	acid -l thread pid
	threads()

to get a list of what each thread is doing.  If you look
at the ones sending or receiving, you should be able to
work out why the deadlock happens.

Russ