Which IPC for passing control?
Don Speck
speck at cit-vax.ARPA
Wed Mar 20 17:40:51 AEST 1985
What is the fastest way to "hand off the torch" from one
cooperating user process to another?
Scenario: I have two processes, A and B, which are running
a relay race, so to speak. "A" is running, and "B" is waiting for
"A"; the goal is for "B" to begin its part of the task as soon as
possible (a couple of milliseconds?) after A finishes its part.
What IPC mechanism should A use to inform B that it's B's turn to
work? Three mechanisms spring to mind:
1) Make "A" be a child of "B", have B wait() for A, and let A
exit. This is not acceptable, process A must run the next
leg of the race very soon, and needs to be there to do it.
2) Connect them with a pipe or socket, and have "A" send a one-
byte message to "B".
Question: after "A" sends the byte, which process is
running? The write() on the pipe/socket is not expected to
block - the pipe was empty - so it seems that "A" will continue
running until blocked for some unrelated reason. Meanwhile "B"
cannot run until "A" relinquishes the CPU. Is this a correct
analysis? This is what I've tried so far, and it's not as fast
as I first expected; according to vmstat, the processes switch
context 2-3 times as often as expected.
3) Have "B" pause() waiting for "A" to send a signal. Question
again: when "A" signals "B", does this trigger the scheduler?
To be as fast as I'm looking for, it is not sufficient for "B"
to be awakened quickly: "A" must immediately stop running.
"A" will require CPU time to recover for the next round, but
that should wait until after "B" has gotten started. Sleep(1)
will do that, but one second is much too long a pause.
4) Others?
This is not a real-time process - if the time goal is not met, the
process simply takes longer - so please no flames about real-time
kernel hacks. I intend to stick to user-mode C code. I am using
4.2bsd, but would also love to hear how it works on earlier Unixes.
Don Speck speck at cit-vax.arpa ihnp4!cithep!cit-vax!speck
More information about the Comp.unix.wizards
mailing list