Xref: utzoo comp.sys.amiga:16542 comp.sys.amiga.tech:99 Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!rutgers!columbia!cunixc!suh From: suh@cunixc.columbia.edu (Kenneth Suh) Newsgroups: comp.sys.amiga,comp.sys.amiga.tech Subject: Re: Some "general" IPC questions..... I think... Message-ID: <507@cunixc.columbia.edu> Date: 23 Mar 88 01:30:02 GMT References: <9490@sunybcs.UUCP> Reply-To: suh@cunixc.columbia.edu (Kenneth Suh) Organization: Columbia University Lines: 109 Keywords: Actual message passing "system".. overhead.... Summary: Blackboard idea isn't too hot... 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