From gmt Wed Jan 3 10:27:20 1990 Date: Wed, 3 Jan 90 10:27:20 MST From: "Gregg Townsend" Message-Id: <9001031727.AA22646@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA22646; Wed, 3 Jan 90 10:27:20 MST To: info-sr Subject: The SR project has moved The SR project's home machine, formerly "arizona.edu", has changed its Internet domain name to "cs.arizona.edu". The uucp sitename of "arizona" has not changed. FTP files from: cs.arizona.edu (128.196.128.118 or 192.12.69.1) Send questions to: sr-project@cs.arizona.edu uunet!arizona!sr-project Mailing list contributions: info-sr@cs.arizona.edu uunet!arizona!info-sr Changes of address: info-sr-request@cs.arizona.edu uunet!arizona!info-sr-request From ntmtv!daemon@ames.arc.nasa.gov Fri Mar 2 15:37:24 1990 From: ntmtv!daemon@ames.arc.nasa.gov Received: from ames.arc.nasa.gov by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP id AA03203; Fri, 2 Mar 90 15:37:24 MST Received: by ames.arc.nasa.gov (5.61/1.2); Fri, 2 Mar 90 14:34:55 -0800 Received: by ntmtv.com (3.2/SMI-3.2) id AA07762; Fri, 2 Mar 90 13:56:26 PST Date: Fri, 2 Mar 90 13:56:26 PST Message-Id: <9003022156.AA07762@ntmtv.com> To: ames!info-sr@cs.arizona.edu, ames!sr-project@cs.arizona.edu Received: from alpet.ntmtv.com by ntmtv.com (3.2/SMI-3.2) id AA07755; Fri, 2 Mar 90 13:56:23 PST Received: by alpet.ntmtv.com (4.0/SMI-4.0) id AA01732; Fri, 2 Mar 90 13:54:31 PST Date: Fri, 2 Mar 90 13:54:31 PST From: hildum@alpet (Eric Hildum) Message-Id: <9003022154.AA01732@alpet.ntmtv.com> To: info-sr@cs.arizona.edu Subject: Porting SR to a Motorola System V/68 Cc: sr-project@cs.arizona.edu I am currently working on porting SR to a Motorola System V/68, which is a 68000 family, AT&T System V release 3 version 0 Unix box. I would like to know: A. Has anyone done a similar port, or is working on a similar port? B. How can I do this port such that it will be useful to other users of the SR language. C. Suggestions, comments, and hints as to what to watch out for, how to change things, etc. I have discovered that the C compiler and lint are more limited on this machine. What compiles without trouble, and passes lint on a Sun3 with K&R C does not compile correctly (enumeration type clashes on operator =; cpp seems to have a problem as well), nor does lint operate (failures including the .h files). I think I am running into hidden limits in the C compiler. Confirmation and suggestions are most welcome... Eric Hildum Northern Telecom, Mountain View ntmtv!hildum@amdahl.com hildum@iris.ucdavis.edu (415)940-2209 From gmt Mon Mar 5 11:29:19 1990 Date: Mon, 5 Mar 90 11:29:19 MST From: "Gregg Townsend" Message-Id: <9003051829.AA09470@megaron.cs.arizona.edu> Received: by megaron.cs.arizona.edu (5.59-1.7/15) id AA09470; Mon, 5 Mar 90 11:29:19 MST In-Reply-To: <9003022156.AA07762@ntmtv.com> To: info-sr Subject: Re: Porting SR to a Motorola System V/68 Cc: ntmtv!hildum@amdahl.com From ntmtv!hildum@amdahl.com Fri Mar 2 15:37:32 1990 I am currently working on porting SR to a Motorola System V/68, which is a 68000 family, AT&T System V release 3 version 0 Unix box.... The file "doc/port.ms", in the SR distribution, contains my thoughts on porting SR to a new architecture, so I won't try to repeat all of that here. Be sure to start with SR 1.1 (the July '89 version); it's much more portable that SR 1.0. The HP 9000/300 is a 68000 box using System V, so that's probably the closest existing port. Look for #ifdef hp9000s300 in a couple of places. Probably the best thing you can do to help others is to mail problem reports back to sr-project@cs.arizona.edu, so that we can try and address them in the next version. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From ssi!fanning!rmb@uunet.UU.NET Tue Mar 6 20:35:32 1990 Received: from uunet.UU.NET by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP id AA22933; Tue, 6 Mar 90 20:35:32 MST Received: from ssi.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA23625; Tue, 6 Mar 90 22:35:18 -0500 Received: from fanning.com by ssi (4.0/SMI-4.0) id AA20979; Tue, 6 Mar 90 17:03:47 CST Received: by fanning.com (4.0/SMI-4.0) id AA00766; Tue, 6 Mar 90 17:03:39 CST Date: Tue, 6 Mar 90 17:03:39 CST From: ssi!fanning!rmb@uunet.UU.NET (Keptin Komrade Dr. Bobwrench III) Message-Id: <9003062303.AA00766@fanning.com> To: uunet!cs.arizona.edu!info-sr@uunet.UU.NET Subject: address change My address is changing from uunet!ssi!fanning!rmb to uunet!ssi!rmb. Please update the mailing list. Thanks, bob bownes. From ntmtv!daemon@ames.arc.nasa.gov Thu Mar 22 15:36:38 1990 From: ntmtv!daemon@ames.arc.nasa.gov Received: from ames.arc.nasa.gov by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP id AA08228; Thu, 22 Mar 90 15:36:38 MST Received: by ames.arc.nasa.gov (5.61/1.2); Thu, 22 Mar 90 14:36:44 -0800 Received: by ntmtv.com (3.2/SMI-3.2) id AA22326; Thu, 22 Mar 90 13:48:59 PST Date: Thu, 22 Mar 90 13:48:59 PST Message-Id: <9003222148.AA22326@ntmtv.com> To: ames!info-sr@cs.arizona.edu Received: from alpet.ntmtv.com by ntmtv.com (3.2/SMI-3.2) id AA22320; Thu, 22 Mar 90 13:48:55 PST Received: by alpet.ntmtv.com (4.0/SMI-4.0) id AA00890; Thu, 22 Mar 90 13:46:59 PST Date: Thu, 22 Mar 90 13:46:59 PST From: hildum@alpet (Eric Hildum) Message-Id: <9003222146.AA00890@alpet.ntmtv.com> To: info-sr@cs.arizona.edu Subject: SR as a distributed applications controller Cc: Fred.Bossler.4K34@bnrmtv I am looking into using SR as a distributed applications controller. In this role the SR application will need to: 1. monitor the execution of a number of separate processes on one or more hosts, initiating execution or restarting execution of the processes should they terminate for some reason. This may involve checking dependencies between processes (some may need to start earlier than others.) 2. allow adminstrative and maintenance control and testing of the processes and their databases (ie, provide an interface such that the administration and control of these processes may take place through one location). In addition, print and message logging services should be centralized. 3. Provide message passing, RPC, etc. services as needed between the different processes. Note that the other processes will be written in C, but may be linked with library procedures as required. The processes are separate processes, and may be updated at different times, or may not be present at all. We can probably get away with linking at installation time, which may help with communications. I would be interested in hearing from anybody who has done an application like this, or has any suggestions or comments as to how it should be done. Thank you, Eric Hildum Northern Telecom (415)940-2209 ntmtv!hildum@amdahl.com hildum@iris.ucdavis.edu From angst@batserver.cs.uq.OZ.AU Tue May 1 00:21:03 1990 Received: from munnari.OZ.AU by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP id AA24169; Tue, 1 May 90 00:21:03 MST Received: from batserver.cs.uq.oz (via metro) by munnari.oz.au with SunIII (5.61+IDA+MU) id AA08449; Tue, 1 May 1990 17:14:01 +1000 (from angst@batserver.cs.uq.OZ.AU for info-sr@cs.arizona.edu) Message-Id: <9005010442.AA14348@client> To: info-sr@cs.arizona.edu Subject: Casting with pointers and type sizes Date: Tue, 01 May 90 14:42:54 +1000 From: Andrew Moran Is it possible in SR to say ADDR(X), where X is and int and ADDR is a pointer ? Also, what is the mechanism for finding out the size of a type ? Angst --------- "He's mad, totally mad. He's madder than Mad Jack McMad, winner of last year's Mr. Madman competition." -- Edmund, a butler. ---------------- From gmt Tue May 1 09:16:52 1990 Received: from owl.cs.arizona.edu by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP id AA22025; Tue, 1 May 90 09:16:52 MST Date: Tue, 1 May 90 09:16:47 MST From: "Gregg Townsend" Message-Id: <9005011616.AA25519@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Tue, 1 May 90 09:16:47 MST To: angst@batserver.cs.uq.OZ.AU, info-sr Subject: Re: Casting with pointers and type sizes Is it possible in SR to say ADDR(X), where X is and int and ADDR is a pointer ? No. If I understand what you're trying to do, the best way right now is assign "ADDR + X" to another variable Y, and then reference "Y^". Also, what is the mechanism for finding out the size of a type ? There isn't one, but you can allocate variables of a type via "new()" without knowing the type's size, if that helps. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From ntmtv!daemon@ames.arc.nasa.gov Tue May 1 11:31:58 1990 From: ntmtv!daemon@ames.arc.nasa.gov Received: from ames.arc.nasa.gov by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP id AA01512; Tue, 1 May 90 11:31:58 MST Received: by ames.arc.nasa.gov (5.61/1.2); Tue, 1 May 90 11:31:46 -0700 Received: by ntmtv.com (3.2/SMI-3.2) id AA01553; Tue, 1 May 90 11:00:21 PDT Date: Tue, 1 May 90 11:00:21 PDT Message-Id: <9005011800.AA01553@ntmtv.com> To: ames!gmt@cs.arizona.edu, ames!info-sr@cs.arizona.edu Received: from alpet.ntmtv.com by ntmtv.com (3.2/SMI-3.2) id AA01546; Tue, 1 May 90 11:00:18 PDT Received: by alpet.ntmtv.com (4.0/SMI-4.0) id AA05546; Tue, 1 May 90 10:57:26 PDT Date: Tue, 1 May 90 10:57:26 PDT From: hildum@alpet (Eric Hildum) Message-Id: <9005011757.AA05546@alpet.ntmtv.com> To: gmt@cs.arizona.edu Subject: Re: Porting SR to a Motorola System V/68 Cc: info-sr@cs.arizona.edu Gregg, We have recently received a new Motorola system, with their next release of UNIX. It appears slightly different, in that the socket library is now included in the c library as is done with 4.x systems. This means that the changes I made to incorporate the library "inet" are no longer needed. I have been a little busy of late, so have not been able to come up with a new differences file for you. I will send my changes as soon as possible. Eric Hildum From angst@batserver.cs.uq.OZ.AU Tue May 1 23:09:24 1990 Received: from munnari.OZ.AU by megaron.cs.arizona.edu (5.59-1.7/15) via SMTP id AA17410; Tue, 1 May 90 23:09:24 MST Received: from batserver.cs.uq.oz (via metro) by munnari.oz.au with SunIII (5.61+IDA+MU) id AA04649; Wed, 2 May 1990 16:09:15 +1000 (from angst@batserver.cs.uq.OZ.AU for info-sr@cs.arizona.edu) Message-Id: <9005020043.AA25850@client> To: info-sr@cs.arizona.edu Subject: Re: Casting with pointers and type sizes In-Reply-To: Your message of Tue, 01 May 90 09:16:47 -0700. <9005011616.AA25519@owl.cs.arizona.edu> Date: Wed, 02 May 90 10:43:52 +1000 From: Andrew Moran > Is it possible in SR to say ADDR(X), where X is and int and ADDR > is a pointer ? >No. If I understand what you're trying to do, the best way right now >is assign "ADDR + X" to another variable Y, and then reference "Y^". Well, what I want is an equivalent to "(TYPE *) 0" actually. I suppose "null" works for all pointer types though, doesn't it, silly me. > Also, what is the mechanism for finding out the size of a type ? >There isn't one, but you can allocate variables of a type via "new()" >without knowing the type's size, if that helps. I need to allocate a big block of memory once (it's a heap for an abstract machine), so I want to know exactly the right number to give malloc. For example, if the elements of my heap are composed of an enum, a ref_count and two pointers, then what is the 200000*size(heap_element) ? Is there anyway I can force the SR compiler to use shorts/chars or something rather than fully-fledged ints for the first two fields ? This reduces size(heap_element) from 4 words to 3 -- very desirable. Also, I'm having trouble with semaphores, specifically I wish to include a semaphore field in a record. This is intended to enable me to protect an instance of a record from being fiddled with by more than more process simultaneously (sheathing the "fiddling" code isn't enough, I want to make the elements critical, not the whole structure). > Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 > +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m Angst ------------- "The eyes are open, the mouth moves, but Mr. Brain has long since departed, hasn't he Percy" --- Lord Edmund BlackAdder, to Lord Percy Percy. ------------------- From gmt Wed May 2 19:10:30 1990 Received: from owl.cs.arizona.edu by megaron (5.59-1.7/15) via SMTP id AA19317; Wed, 2 May 90 19:10:30 MST Date: Wed, 2 May 90 16:11:49 MST From: "Gregg Townsend" Message-Id: <9005022311.AA02130@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Wed, 2 May 90 16:11:49 MST To: angst@batserver.cs.uq.OZ.AU Subject: Re: Casting with pointers and type sizes Cc: info-sr From: Andrew Moran I need to allocate a big block of memory once (it's a heap for an abstract machine), so I want to know exactly the right number to give malloc. For example, if the elements of my heap are composed of an enum, a ref_count and two pointers, then what is the 200000*size(heap_element) ? The easiest way to do something like this in SR is to let the system figure it all out and allocate it, e.g.: type t = rec ( e : enum ( red, green, blue ) r : int p : ptr t q : ptr any ) const n := 200000 var a[n] : t # declare array of 200000 records Is there anyway I can force the SR compiler to use shorts/chars or something rather than fully-fledged ints for the first two fields ? This reduces size(heap_element) from 4 words to 3 -- very desirable. There's no easy way to do that. It is possible to declare fields as chars and explicitly convert to & from other types. SR has no way to use shorts. Also, I'm having trouble with semaphores, specifically I wish to include a semaphore field in a record. This is intended to enable me to protect an instance of a record from being fiddled with by more than more process simultaneously (sheathing the "fiddling" code isn't enough, I want to make the elements critical, not the whole structure). This is also tricky. An SR semaphore declares an op, not a variable, so semaphores can't be used in records. One approach would be to have an "array" of semaphores, then associate a different one with each record (perhaps by storing a unique semaphore index in the record). Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From angst@batserver.cs.uq.OZ.AU Sat Jun 23 01:35:24 1990 Received: from munnari.oz.au by megaron (5.61/15) via SMTP id AA09579; Sat, 23 Jun 90 01:35:24 -0700 Received: from batserver.cs.uq.oz (via metro) by munnari.oz.au with SunIII (5.61+IDA+MU) id AA02222; Sat, 23 Jun 1990 18:35:08 +1000 (from angst@batserver.cs.uq.OZ.AU for info-sr@cs.arizona.edu) Message-Id: <9006210724.AA06496@client> To: info-sr@cs.arizona.edu Subject: How are enumerated types represented + process priority Date: Thu, 21 Jun 90 17:24:19 +1000 From: Andrew Moran Is a variable of an enumerated type the same size as an int or do they fit into chars ? Can I cast an enum to a char ? Can I influence the priority of a process ? Angst ---------- "Tell the King that he's as safe as a fox being hunted by a pack of one-legged hunting tortoises." -- Lord Edmund Blackadder, loyalist ----------------- From gmt Mon Jun 25 07:21:09 1990 Received: from owl.cs.arizona.edu by megaron (5.61/15) via SMTP id AA07136; Mon, 25 Jun 90 07:21:09 -0700 Date: Mon, 25 Jun 90 07:21:05 MST From: "Gregg Townsend" Message-Id: <9006251421.AA15457@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Mon, 25 Jun 90 07:21:05 MST To: info-sr Subject: Re: How are enumerated types represented + process priority Date: Thu, 21 Jun 90 17:24:19 +1000 From: Andrew Moran Is a variable of an enumerated type the same size as an int or do they fit into chars ? SR always stores enums as ints, at least right now. (Nothing is promised.) Can I cast an enum to a char ? Yes, and vice versa. Can I influence the priority of a process ? Not yet, but we're working on it. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From morgenst@tcucs1.cs.tcu.EDU Sat Aug 18 15:17:59 1990 Received: from ALPHA.IS.TCU.EDU ([129.117.15.2]) by megaron (5.61/15) via SMTP id AA23903; Sat, 18 Aug 90 15:17:59 -0700 Received: from tcucs1.cs.tcu.edu. by ALPHA.IS.TCU.EDU; Sat, 18 Aug 90 17:19 CDT Received: by tcucs1.cs.tcu.edu. (4.0/SMI-4.0) id AA03603; Sat, 18 Aug 90 17:18:31 CDT Date: Sat, 18 Aug 90 17:18:31 CDT From: morgenst@tcucs1.cs.tcu.EDU Subject: srx lost connection??? To: info-sr@cs.arizona.edu Message-Id: <9008182218.AA03603@tcucs1.cs.tcu.edu.> X-Envelope-To: info-sr@cs.arizona.EDU A week ago we came online to internet. Before that time, we had no problem running SR programs across our local network of SUN3s and SparcStations (provided that the main resource was run on a SparcStation). Now we are getting errors of the form: srx: lost connection to virtual machine when we try start up a vm on a SUN3 from a main resource running on a SparcStation. This message gets generated even when running the simple program in sr/examples/remote. Does anyone know if this problem is resolvable or what is causing it? We currently are not running yellow pages, we do not have a local nameserver and we are not running in.routed (a router is specified using "route" in rc.local). Thanks in advance for you help!!! Craig Morgenstern Dept of Computer Science Texas Christian University morgenst@tcucs1.cs.tcu.edu From morgenst@tcucs1.cs.tcu.EDU Sat Aug 18 21:58:34 1990 Received: from ALPHA.IS.TCU.EDU ([129.117.15.2]) by megaron (5.61/15) via SMTP id AA02785; Sat, 18 Aug 90 21:58:34 -0700 Received: from tcucs1.cs.tcu.edu. by ALPHA.IS.TCU.EDU; Sun, 19 Aug 90 00:00 CDT Received: by tcucs1.cs.tcu.edu. (4.0/SMI-4.0) id AA04591; Sat, 18 Aug 90 23:59:06 CDT Date: Sat, 18 Aug 90 23:59:06 CDT From: morgenst@tcucs1.cs.tcu.EDU Subject: srx lost connection To: info-sr@cs.arizona.edu Message-Id: <9008190459.AA04591@tcucs1.cs.tcu.edu.> X-Envelope-To: info-sr@cs.arizona.EDU Please ignore my last request for help. We seem to be having network problems not specific to SR on our SparcStations. Craig Morgenstern morgenst@tcucs1.cs.tcu.edu From angst@batserver.cs.uq.OZ.AU Wed Oct 10 21:29:28 1990 Received: from munnari.oz.au by megaron.cs.arizona.edu (5.61/15) via SMTP id AA01197; Wed, 10 Oct 90 21:29:28 -0700 Received: from batserver.cs.uq.oz (via metro) by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA25628; Thu, 11 Oct 1990 14:29:18 +1000 (from angst@batserver.cs.uq.OZ.AU for info-sr@cs.arizona.edu) Message-Id: <9010110429.25628@munnari.oz.au> To: info-sr@cs.arizona.edu Subject: Can operation capabilities be included in records ? Semaphores ? Date: Thu, 11 Oct 90 14:19:04 +1000 From: Andrew Moran I am trying to gain mutual exclusion over elements of a data type (i.e. no simulaneous operations on any instance of the data type). To this end, I would like to include in the data type a semaphore (rather, an operation capability that mimics a semaphore since semaphores cannot be variables as far as I can tell). I've run into quite a few problems when trying to initialise an instance. Assume the following declarations. optype LockSem () type SemRec = rec (data_bits : Data; lock : cap LockSem) op new_semrec (data : Data) returns sr : Sem Rec The lock field is intended to be the means of exclusion. When I want to change/access the record I use "receive lock ()"; when I want to release the lock I use "send lock ()". Is there any way I can actually meaningfully assign to the lock field ? I've tried proc new_semrec (data) returns sr sr := new(SemRec) sr^.data := data op lock_sem : LockSem sr^.lock := lock_sem send sr^.lock () /* So the record can be used immediately */ end new_semrec but, as common sense would dictate, this doesn't work since lock_sem has not been implemented. Is there any way around this Gregg ? Or have I overstepped the bounds of decent SR programming. Andrew Moran --------- "He's mad, totally mad. He's madder than Mad Jack McMad, winner of last year's Mr. Madman competition." -- Edmund, a butler. ---------------- From olsson@ivy.eecs.ucdavis.edu Tue Oct 16 13:30:03 1990 Received: from iris.eecs.ucdavis.edu by megaron.cs.arizona.edu (5.61/15) via SMTP id AA01141; Tue, 16 Oct 90 13:30:03 -0700 Received: by iris.eecs.ucdavis.edu (5.57/UCD.EECS.3.0) id AA12512; Tue, 16 Oct 90 13:29:44 -0700 Received: by ivy (5.57/3.14) id AA04050; Tue, 16 Oct 90 13:29:21 -0700 Date: Tue, 16 Oct 90 13:29:21 -0700 From: olsson@ivy.eecs.ucdavis.edu (Ron Olsson) Message-Id: <9010162029.AA04050@ivy> To: angst@batserver.cs.uq.oz.au Cc: info-sr@cs.arizona.edu In-Reply-To: Andrew Moran's message of Thu, 11 Oct 90 14:19:04 +1000 <9010110429.25628@munnari.oz.au> Subject: Can operation capabilities be included in records ? Semaphores ? Date: Thu, 11 Oct 90 14:19:04 +1000 From: Andrew Moran ... The lock field is intended to be the means of exclusion. When I want to change/access the record I use "receive lock ()"; when I want to release the lock I use "send lock ()". Is there any way I can actually meaningfully assign to the lock field ? I've tried proc new_semrec (data) returns sr sr := new(SemRec) sr^.data := data op lock_sem : LockSem sr^.lock := lock_sem send sr^.lock () /* So the record can be used immediately */ end new_semrec but, as common sense would dictate, this doesn't work since lock_sem has not been implemented. Right. A general way to solve this is something like: proc new_semrec (data) returns sr sr := new(SemRec) sr^.data := data op req_lock, rel_lock : LockSem sr^.req_lock := req_lock sr^.rel_lock := rel_lock reply do true -> receive req_lock(); receive rel_lock(); od end new_semrec I've changed the interface to call sr^.req_lock(); /* use sr */; send sr^.rel_lock() (And not shown, but obvious, the decl of SemRec.) I'm not sure, though, that you didn't already figure out this kind of solution but were looking for a better way, one that uses your interface. Note that each new_semrec process hangs around forever -- that can be tidied up if you know when no one will use the record anymore. If all the processes using the record are in the same resource instance and you can bound the number of records that will ever be in existence at once, then you might want to use an array of shared operations. That would allow you to use the interface you want, e.g., receive lock[sr^.i]; /* use sr */; send lock[sr^.i()] where the index i is assigned by new_semrec. If using processes are outside the resource, you can provide procs in the resource they can call to do the receive/send on their behalf. From angst@batserver.cs.uq.OZ.AU Tue Oct 16 16:49:15 1990 Received: from munnari.oz.au by megaron.cs.arizona.edu (5.61/15) via SMTP id AA11550; Tue, 16 Oct 90 16:49:15 -0700 Received: from batserver.cs.uq.oz (via metro) by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA08353; Wed, 17 Oct 1990 09:49:01 +1000 (from angst@batserver.cs.uq.OZ.AU for info-sr@cs.arizona.edu) Message-Id: <9010162349.8353@munnari.oz.au> To: info-sr@cs.arizona.edu Subject: Re: Ron Olsson's reply to "Can operation capabilities .... " In-Reply-To: Your message of "Tue, 16 Oct 90 13:29:21 MST." <9010162029.AA04050@ivy> Date: Wed, 17 Oct 90 09:14:05 +1000 From: Andrew Moran > Right. A general way to solve this is something like: > > proc new_semrec (data) returns sr > sr := new(SemRec) > sr^.data := data > op req_lock, rel_lock : LockSem > sr^.req_lock := req_lock > sr^.rel_lock := rel_lock > reply > do true -> receive req_lock(); receive rel_lock(); od > end new_semrec Thanks Ron, good stuff. I thought some kind of "reply then wait for invocations" structure would be required, I just couldn't get it to mesh. > I've changed the interface to > call sr^.req_lock(); /* use sr */; send sr^.rel_lock() Fine, suits me fine. You see I want to lock elements of the heap of a parallel functional abstract machine (for evaluation). I will know when a heap element is not used anymore, but the usual response is to add it to the free list. This will mean the new_semrec (new_cell actually) process will still be alive. If I do away with the free list, I can be rid of the new_cell process. However, this is merely a prototype of the abstract machine, in which the memory management (particularly allocation of heap space) is very unsophisticated (i.e. uses "new", rather than allocating explicitly from a heap as all responsible abstract machines do). If I rid myself of the free list now, it will make the step from prototype to real machine much more difficult. Anyway, at the moment the only benefit gained from having a free list is that you don't need to call new_cell (I think the new(CELL) is the time-consuming procedure) thus saving some time. But with the process hanging around, I'm wondering what the time/space cost will be. Also, it is likely that there will be large numbers of these new_cell processes simultaneously active. Is there some limit to the number of active SR processes I can have at one time ? What about the speed (and space) degradation involved in having heaps of Sr processes running about ? > If all the processes using the record are in the same resource > instance and you can bound the number of records that will ever be in > existence at once, then you might want to use an array of shared > operations. That would allow you to use the interface you want, e.g., > receive lock[sr^.i]; /* use sr */; send lock[sr^.i()] > where the index i is assigned by new_semrec. The using processes will never be in the same resource, and the bound on the heap size is huge (even though it is not enforced in the prototype). I don't like the idea of an array of 100 000 operations. A "free list" of shared operations, perhaps ? That's the same as keeping the free list of heap elements with operation attached to each element. Back to square one. > If using processes are outside the resource, you can provide procs in > the resource they can call to do the receive/send on their behalf. Yep. What Ron has suggested is what I was after, the only question that now remains is "to free or not to free ?" That is, should I keep the free list as it is (enabling easy extension of the prototype) or will I be forced (for performance considerations) to abandon it ? To summarize, these are now the question of interest: 1. What does it cost in time and space to have an SR process active (waiting for the most part) throughout execution of the program ? 2. How many SR processes may be active simultaneously ? 3. What sort of performance degradation can I expect as the number of active SR processes increases ? Thanks people, Angst --------------- Left. G: "Sir, what do we do if we stand on a mine ?" Capt. B: "Well, normal procedure, Leftenant, is to jump 200 feet into the air and scatter oneself over a wide area." -- somewhere no man's land, "Blackadder Goes Forth" --------------- From olsson@ivy.eecs.ucdavis.edu Wed Oct 17 11:35:58 1990 Received: from iris.eecs.ucdavis.edu by megaron.cs.arizona.edu (5.61/15) via SMTP id AA22341; Wed, 17 Oct 90 11:35:58 -0700 Received: by iris.eecs.ucdavis.edu (5.57/UCD.EECS.3.0) id AA13975; Wed, 17 Oct 90 11:35:55 -0700 Received: by ivy (5.57/3.14) id AA08117; Wed, 17 Oct 90 11:35:53 -0700 Date: Wed, 17 Oct 90 11:35:53 -0700 From: olsson@ivy.eecs.ucdavis.edu (Ron Olsson) Message-Id: <9010171835.AA08117@ivy> To: angst@batserver.cs.uq.oz.au Cc: info-sr@cs.arizona.edu In-Reply-To: Andrew Moran's message of Wed, 17 Oct 90 09:14:05 +1000 <9010162349.8353@munnari.oz.au> Subject: Ron Olsson's reply to "Can operation capabilities .... " Date: Wed, 17 Oct 90 09:14:05 +1000 From: Andrew Moran ... To summarize, these are now the question of interest: 1. What does it cost in time and space to have an SR process active (waiting for the most part) throughout execution of the program ? 2. How many SR processes may be active simultaneously ? 3. What sort of performance degradation can I expect as the number of active SR processes increases ? The max number of processes per vm is bounded. `srl -l' will list the limits, and the srl options that control them. Each process takes space for stack (also controllable via srl option). So, memory to hold program can get large if you have lots of processes. However, that shouldn't affect execution time (other than perhaps for swapping...). You might run out of virtual memory if you have thousands of processes. BTW, another technique that you might find relevant is to use an SR operation to implement your free list. To obtain an item, receive from the operation; to release an item, send it to the operation. Of course, the receiver must be in the same resource (but a proc to service outside requests could do the dirty work). The SR paper in TOPLAS Jan 88 contains a paragraph describing this technique (page 82, "data-containing semaphores"). I've recently written a paper that describes it in more detail; I'll mail you a copy if you're interested. I don't think this technique will solve your original problem -- you want locking, which seems to indicate that you have multiple processes accessing the same record; this technique allows one process at a time to use an item, and then return it. But the idea might help you in some other aspect of your work. From @CUNYVM.CUNY.EDU:flibedin@taurus.bitnet Wed Nov 21 05:13:18 1990 Resent-From: @CUNYVM.CUNY.EDU:flibedin@taurus.bitnet Received: from Arizona.edu (Hopey.Telcom.Arizona.EDU) by megaron.cs.arizona.edu (5.61/15) via SMTP id AA22004; Wed, 21 Nov 90 05:13:18 -0700 Return-Path: flibedin%TAURUS.BITNET@CUNYVM.CUNY.EDU Received: from cunyvm.cuny.edu by Arizona.edu; Wed, 21 Nov 90 05:12 MST Received: from TAURUS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7719; Wed, 21 Nov 90 07:11:37 EST Received: from s2.math.tau.ac.il by math.tau.ac.il (4.1/TAU-4.8) id AA07621; Wed, 21 Nov 90 14:12:37 +0200 Received: by s2.math.tau.ac.il (4.1/TAUCLNT-2.0) id AA00615; Wed, 21 Nov 90 14:10:29 +0200 Resent-Date: Wed, 21 Nov 90 05:13 MST Date: Wed, 21 Nov 90 14:10:29 +0200 From: flibedin%TAURUS.BITNET@CUNYVM.CUNY.EDU From: flibedin%TAURUS.BITNET@CUNYVM.CUNY.EDU Subject: SSR on Transputers Resent-To: info-sr@cs.arizona.edu To: info-sr@arizona.edu Reply-To: flibedin%math.tau.ac.il@CUNYVM.CUNY.EDU Resent-Message-Id: Message-Id: <9011211210.AA00615@s2.math.tau.ac.il> X-Envelope-To: info-sr@CS.Arizona.EDU X-Vms-To: info-sr@Arizona.edu Comments: If you have trouble reaching this host as math.tau.ac.il Please use the old address: user@taurus.bitnet I would like to know if someone has ported SR to a transputer network running the Helios Operating System? Fernando Libedinsky CS Dept, Tel-Aviv University flibedin@math.tau.ac.il