From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX"  7-APR-1993 18:10:19.11
To:	INFO-VAX@kl.sri.com
CC:	
Subj:	RE: Interrupt Based Inter Process Communications

	I wish to implement interrupt based communications between several
	processes on a VAX 8250 running VMS version 5.1. A signalling process
	would generate an interrupt causing several other processes to
	retrieve and process data from a common global section.

	However, I wish to implement a one way handshake only. ie. The
	signalling  process would generate an interrupt and then clear it -
	this would cause  the receiving processes to enter their corresponding
	interrupt service  routines.

	I don't care about missing a few interrupts - my data is time stamped
	However my signalling process must generate an interrupt *every* time
	a data sample is ready - it must not wait for a return handshake from
	the receiving process(es). Also I do not wish to have interrupts
	queued.

	From reading the manuals and after some experimentation it appears
	that  the general method of implementing interrupt based
	communications between processes is as follows

	1) Process A - the signalling process - sets up a mailbox
	2) Process B - the receiving process - obtains a channel to the
	mailbox set up by process A
	3) Process B then sets either a read or a write attention ast on the
	mailbox
	4) Process A issues either a read or a write request, as appropriate,
	to cause Process B to be interrupted
	5) Process B enters its interrupt service routine and issues either a
	write  or a read request, as appropriate, to clear the interrupt
	"condition".
	6) Repeat steps 3) to 5)

	This above method has a two way handshake which I can't use

	What I've done is as follows

	1) Process A - the signalling process - sets up a mailbox
	2) Process B - the receiving process - obtains a channel to the
	mailbox set up by process A
	3) Process B then sets a write attention ast on the mailbox
	4) Process A generates the interrupt condition as follows
	        i) It sets its priority higher than process B
	       ii) It issues a write to the mailbox to generate the interrupt
		condition
	      iii) It issues a read to the mailbox to clear the interrupt
		 condition
	       iv) It sets its priority back down again
	   5) Process B enters its interrupt service routine
	   6) Repeat steps 3) to 5)

	Note that in step 4 I had to up the priority of process A to insure
	that the qiow write and the qiow read to the mailbox occurred as a
	single unit. If processs A gets suspended between the qiow write and
	the qiow read to the mailbox then this will cause process B to be
	interrupted continuously - which I don't want.

	Can someone suggest a better method of implementing interrupt based
	process communications without a two way handshake - I really dislike
	this kludge.

With good reason:  It's absolutely unreliable.  For one thing, the first time
you run it on a multiprocessor, it'll likely break as both A and B run at the
same time.

You know, I HATE these "I want to do XXX with one hand tied behind my back"
questions.  What does it mean to say you "can't use a two-way handshake"?  Are
you really trying to say that you are unable to add any code to the receiving
process?  In that case, you are out of luck:  There's simply no way to do what
you want without SOME cooperation from the receiving process, one way or
another.

Of course, you are already requiring B to open the mailbox and hang a QIO off
it continuously.  What, then, does this restriction mean?

Internally, VMS has a very general mechanism for sending AST's to other
processes.  In some cases, the target code of the AST is actually common
code mapped in system space by all processes.  In other cases, the sending
process allocates some memory from space, writes the code to be executed in
there, and uses the allocated space as the target.  In either case, the
sender knows of the existence, at least logically, of some specific code in
the receiving process.  It's actually no big deal to write a user-written
system service to provide the same ability to user-mode programs, and several
such services have appeared on the net over the years.

The closest you can come with the normal VMS set is to use $FORCEX.  $FORCEX
is implemented by sending a user-mode AST to the receiving process, specifying
as the target some code within VMS that will simply call $EXIT with the AST
parameter as the argument.  For an "unprepared" process, this does about all
you can expect in this situation:  It forces the program into the known exit
path.  A prepared program, if it wished, could declare an exit handler which
would prevent the exit from occuring.  (It's unfortunate that the exit condi-
tion isn't passed to the exit handler, so you have to look at where you are
called from to figure out if this is a normal $EXIT or a $FORCEX call.  All
quite non-supported, but not too complicate - Ehud Gavron worked out all the
details at one point, perhaps he'll send you a copy of the code.)

Having worked with code with this structure - data in shared memory that you
want to notify the receiver about - my own experience is that there is usually
a better approach than searching for the missing "send an interrupt" service.
Where you really DO need to interrupt another process, using a blocking AST
is better (faster) than a mailbox, if a bit more complex to set up.

Tempting as the ability to "just interrupt" an unprepared process may be, it
does not, in my experience, fit in to any decently designed piece of code.

							-- Jerry