ugmiker@sunybcs (Michael Reilly) (03/22/88)
I have a couple of questions about the ipc ideas floating around
so far, they mostly have to do with overhead of a few of the proposals
talked about to date. These questions might be slightly redundant, or
taken for granted on the net so far, but I am just wondering what memory, or
cpu, hogging we are willing to give to this ipc library, or broker...???
How much memory would our ipc.library take up, would it be a large
enough amount of space to make us think about a different type of system?
With the object oriented approach (which I like) how will each
process talk to the other processes? There are a few different ways we
could implement this, each with thier own drawbacks...
1) The old process to processs line, much like a person to person
phone line, it would (i guess) be implemented as a pipe/port
that would be used to read and write messages from and to the
two process, much like unix IPC.
Problems: how do these two processes get together, is there
some central "message broker" or operator that would connect
a process that "wants something done" to a process that "can
do that something". But then there is also the overhead of
the operator, and the problem of each new process coming in,
"logging" in with the operator. Also where is the operator
going to keep the lists of who does what, and who wants what,
and where to find each program, if it does not exist in the
system at the time.
2) A blackboard, or party line communication method, where each process
reads and writes to one piece of "shared" memory. The processes
"write" on the blackboard, and tell all the other processes what it
can do, and reads what all of the other processes need done.
Problems:how big is this "shared" memory, of course it should
be dynamically sized, but how large would we want it to get, and
how long should a message stay on the blackboard before getting
"erased", if a messge doesn't get replied to, but we know we
want every message replied to.
3) a reserved spot, or mailbox method, where each process knows where to
check if it is wanted to do something, so it would not have to read
the whole blackboard, and also knows where to send to when it's
requests for help on certain projects.
Problems:This again means any process that needs something has
to know where to find the help it needs, or where to look to
find the help it needs. Or each process has to send a copy of
the help it needs to every process with a mailbox, to see if
any of them can help.
4) a combination of 2 and 3, a reserved blackboard method, with a
special areas of the blackboard reserved for special types of
functions, or special "groups" of "objects" in our object oriented
method.
problems: problems for this would be a restricted (hopefully)
union of the problems of 2 and 3...
With the "ways and means" method, how large would this "ways and means"
program be??? it seems like it has alot of jobs, would it be excessively large??
just wondering....
mike
Mike Reilly President of UGCSA University of Buffalo Computer Science
csnet: ugmiker@buffalo.CSNET
uucp: ..!{nike|watmath,alegra,decvax}!sunybcs!ugmiker
BITNET: ugmiker@sunybcs.BITNET <-OR-> ACSCMPR@ubvmsc.BITNETsuh@cunixc.columbia.edu (Kenneth Suh) (03/23/88)
In article <9490@sunybcs.UUCP> ugmiker@sunybcs.UUCP (Michael Reilly) writes: >There are a few different ways we >could implement this, each with thier own drawbacks... > > 2) A blackboard, or party line communication method, where each process > reads and writes to one piece of "shared" memory. The processes > "write" on the blackboard, and tell all the other processes what it > can do, and reads what all of the other processes need done. > Problems:how big is this "shared" memory, of course it should > be dynamically sized, but how large would we want it to get, and > how long should a message stay on the blackboard before getting > "erased", if a messge doesn't get replied to, but we know we > want every message replied to. I don't think that the real problem is how big we should make shared memory. The size of shared memory doesn't make a difference when you want to prevent different processes from overwriting wrong sections of shared memory. My question would be how do you propose to keep two processes from writing to the area of shared memory? Do you want to have test and set procedures? Does someone want to port Concurrent Euclid and set up a monitor (oops, going askew again. Yeah, I know that this can be written on a vax and converted into assembly for the 6800.)? > 4) a combination of 2 and 3, a reserved blackboard method, with a > special areas of the blackboard reserved for special types of > functions, or special "groups" of "objects" in our object oriented > method. See above comments... > just wondering.... > mike > >Mike Reilly President of UGCSA University of Buffalo Computer Science >csnet: ugmiker@buffalo.CSNET >uucp: ..!{nike|watmath,alegra,decvax}!sunybcs!ugmiker >BITNET: ugmiker@sunybcs.BITNET <-OR-> ACSCMPR@ubvmsc.BITNET /ken Kenneth Suh PATH: suh@CUNIXC.COLUMBIA.EDU 312 McBain Hall, C/O Carman Hall SY.SUH@CU20B.BITNET Columbia University ..!rutgers!columbia!cunixc!suh New York, NY 10027 Newsgroups: comp.sys.amiga,comp.sys.amiga.tech Subject: Re: Some "general" IPC questions..... I think... Summary: Blackboard idea isn't too hot... Expires: References: <9490@sunybcs.UUCP> Sender: Reply-To: suh@cunixc.columbia.edu (Kenneth Suh) Followup-To: Distribution: Organization: Columbia University Keywords: Actual message passing "system".. overhead.... In article <9490@sunybcs.UUCP> ugmiker@sunybcs.UUCP (Michael Reilly) writes: > With the object oriented approach (which I like) how will each >process talk to the other processes? There are a few different ways we >could implement this, each with thier own drawbacks... > > 2) A blackboard, or party line communication method, where each process > reads and writes to one piece of "shared" memory. The processes > "write" on the blackboard, and tell all the other processes what it > can do, and reads what all of the other processes need done. > Problems:how big is this "shared" memory, of course it should > be dynamically sized, but how large would we want it to get, and > how long should a message stay on the blackboard before getting > "erased", if a messge doesn't get replied to, but we know we > want every message replied to. The problem that I foresee with this idea is how do you keep two processes from writing to the area of shared memory? Do you want to have test and set procedures? Does someone want to port Concurrent Euclid and set up a monitor? > 4) a combination of 2 and 3, a reserved blackboard method, with a > special areas of the blackboard reserved for special types of > functions, or special "groups" of "objects" in our object oriented > method. > problems: problems for this would be a restricted (hopefully) > union of the problems of 2 and 3... See above comments... > just wondering.... > mike > >Mike Reilly President of UGCSA University of Buffalo Computer Science >csnet: ugmiker@buffalo.CSNET >uucp: ..!{nike|watmath,alegra,decvax}!sunybcs!ugmiker >BITNET: ugmiker@sunybcs.BITNET <-OR-> ACSCMPR@ubvmsc.BITNET /ken Kenneth Suh PATH: suh@CUNIXC.COLUMBIA.EDU 312 McBain Hall, C/O Carman Hall SY.SUH@CU20B.BITNET Columbia University ..!rutgers!columbia!cunixc!suh New York, NY 10027
suh@cunixc.columbia.edu (Kenneth Suh) (03/23/88)
Sorry about that last message... /ken Kenneth Suh PATH: suh@CUNIXC.COLUMBIA.EDU 312 McBain Hall, C/O Carman Hall SY.SUH@CU20B.BITNET Columbia University ..!rutgers!columbia!cunixc!suh New York, NY 10027
cmcmanis%pepper@Sun.COM (Chuck McManis) (03/24/88)
In article <507@cunixc.columbia.edu> (Kenneth Suh) writes:
->The problem that I foresee with this idea is how do you keep two
->processes from writing to the area of shared memory? Do you want to
->have test and set procedures? Does someone want to port Concurrent
->Euclid and set up a monitor?
Actually, AmigaDOS has a very capable set of Semaphore routines with
Test and Set calls built in. See the Autodocs.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.craig@unicus.UUCP (Craig D. Hubley) (03/30/88)
In article <9490@sunybcs.UUCP> ugmiker@sunybcs.UUCP (Michael Reilly) writes: > How much memory would our ipc.library take up, would it be a large >enough amount of space to make us think about a different type of system? Well, if that were the case, it wouldn't be much use. The major space-eater would be (as always) the nice interface so that programmers wouldn't have to look for umpteen kinds of standard messages. Those that had big objections to the space used could always look for the messages on the port themselves, but with the caveat that future versions of the protocol might not be compatible. For commercial programs, large anyway, the friendly and safe approach would be preferred. > With the object oriented approach (which I like) how will each >process talk to the other processes? There are a few different ways we >could implement this, each with thier own drawbacks... > > 1) The old process to processs line, much like a person to person > > do that something". But then there is also the overhead of > the operator, and the problem of each new process coming in, > "logging" in with the operator. Also where is the operator > going to keep the lists of who does what, and who wants what, > and where to find each program, if it does not exist in the > system at the time. The `operator', which is a good name by the way, would have to keep the lists of services offered and requested and in use, and would have to run at the same time, as a high-priority process. You might also want to have the option of swapping it out, with all of that information saved to a file, and restoring it when the emergency has passed. But under normal circumstances, it should exist in the system at the same time. The process-to-process line is useful for two programs that must send large amounts of data back and/or forth in small chunks, like a pipe. However, it costs almost nothing to have a broker/waysandmeans/operator perform a `marriage' first, and keep track of their connection until it is broken, and thereby be able to hold off other requests until the service becomes available again. > 2) A blackboard, or party line communication method, where each process > reads and writes to one piece of "shared" memory. The processes > "write" on the blackboard, and tell all the other processes what it > can do, and reads what all of the other processes need done. > Problems:how big is this "shared" memory, of course it should > be dynamically sized, but how large would we want it to get, and > how long should a message stay on the blackboard before getting > "erased", if a messge doesn't get replied to, but we know we > want every message replied to. This model exists also, but the *processes* do not write and check on the blackboard, as this would require them to know much about the system and there would still have to be a `blackboard manager'. Rather, the broker maintains the blackboard and answers questions about it. Messages that are looking for something unavailable will be held until the broker is sure that nothing can be made available for it in time (as defined in the call). This is a matter of seeing if the service required is loaded, seeing if it is in use, and attempting to load it or wait for it to be freed. Some form of pre-emption could be defined, but that would be tricky. The broker itself would have to respond to the message, with a failure. > 3) a reserved spot, or mailbox method, where each process knows where to Having a broker with a well-organized blackboard and its own search methods is nearly as efficient as a well-written `go right to the memory location and see if that bit is a 1' approach, considering that calls would not be made in tight loops. :-) Having processes be as stupid as possible is very desirable. This intelligence belongs on the service level, which is abstracted one level from the process level. I want *all* ANIM viewers to know about my animation, not just JoeAnimator. A mailbox for each type of service is essentially what the broker would implement, at least for messages that were willing to wait around to be answered. > 4) a combination of 2 and 3, a reserved blackboard method, with a > special areas of the blackboard reserved for special types of > functions, or special "groups" of "objects" in our object oriented > method. > problems: problems for this would be a restricted (hopefully) > union of the problems of 2 and 3... I hope the problems would be restricted, too, since that's what I'm thinking of. >With the "ways and means" method, how large would this "ways and means" >program be??? it seems like it has alot of jobs, would it be excessively large?? Yes, it has a lot of jobs, but most of these jobs are a screenful of C, at most. For instance, checking to see whether a service is available at the present time would just be a matter of finding a name in a name table. The port address for that service is just another field in that table. Flagging it as `in use' after sending its address off to another process is just flipping a flag. Loading it if it's not available is looking up a filename, plus the load operation (if this is desired). None of these things is more than a tiny chunk of code, once the data structure of service names, ports that offer them, and programs that fire them up is in place. You might have some lags as you start up, but that's the most time-intensive thing about using an 8 meg machine without virtual memory anyway. > just wondering.... > mike Good questions. I'm going to go away and think about them some more. Craig Hubley, Unicus Corporation, Toronto, Ont. craig@Unicus.COM (Internet) {uunet!mnetor, utzoo!utcsri}!unicus!craig (dumb uucp) mnetor!unicus!craig@uunet.uu.net (dumb arpa)