From nalaka@das.harvard.edu Fri Jan 8 20:18:08 1993 Received: from endor.harvard.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA02010; Fri, 8 Jan 1993 18:18:11 MST Date: Fri, 8 Jan 93 20:18:08 EST From: nalaka@das.harvard.edu (E.M. Nalaka Edirisinghe) Message-Id: <9301090118.AA08315@endor.harvard.edu> To: info-sr@cs.arizona.edu Subject: SR Bug? We are two Harvard Graduate Students currently working on an SR Discrete Event Simulation as a Term Project for a course in Parallel Programming. Unfortunately, we are forced to run this on a single-processor system, although our program utilizes concurrent processes. We have found that once one process finishes, the current iteration is completed for all processes, but future iterations never occur for processes that are not finished. Our program currently runs without the use of any nap()s, blocks, etc that would make a process sleep. We would appreciate receiving as much information as you could send us on this topic, as quickly as possible as our deadline is next week. Thank you very much for your help. Nalaka Edirisinghe Mike Saperstein e-mail: nalaka@endor at Harvard University From yang@riogrande.cs.tcu.edu Fri Jan 22 12:14:19 1993 Resent-Date: 22 Jan 1993 12:14:19 -0600 (CST) Resent-From: yang@riogrande.cs.tcu.edu Received: from Arizona.edu (Merlin.Telcom.Arizona.EDU) by optima.cs.arizona.edu (5.65c/15) via SMTP id AA02622; Fri, 22 Jan 1993 15:33:37 MST Received: from Arizona.edu by Arizona.edu (PMDF #2381 ) id <01GTTOQIRTPS8WZJDN@Arizona.edu>; Fri, 22 Jan 1993 15:33:15 MST Received: from ALPHA.IS.TCU.EDU by Arizona.edu (PMDF #2381 ) id <01GTTOPMI7M8936Z2W@Arizona.edu>; Fri, 22 Jan 1993 15:32:31 MST Received: from riogrande.cs.tcu.edu (TCUCS6.CS.TCU.EDU) by ALPHA.IS.TCU.EDU (PMDF #2903 ) id <01GTTHU75FM8000LWB@ALPHA.IS.TCU.EDU>; Fri, 22 Jan 1993 12:16:07 CST Received: from sanantonio.cs.tcu.edu by riogrande.cs.tcu.edu (4.1/SMI-4.1) id AA17697; Fri, 22 Jan 93 12:14:19 CST Date: 22 Jan 1993 12:14:19 -0600 (CST) From: yang@sanantonio.cs.tcu.edu (Kevin Yang) Subject: Mailing List Resent-To: info-sr@cs.arizona.edu To: info-sr@arizona.edu Resent-Message-Id: <01GTTOQJL10Y8WZJDN@Arizona.edu> Message-Id: <9301221814.AA17697@riogrande.cs.tcu.edu> X-Vms-To: IN%"info-sr@Arizona.edu" Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sent: Fri Jan 22 1993, 12:13:40 CST I would like to join this discussion group. Please enter my name to the mailing list. Thanks, Kevin. From lamq@a570.usal.es Thu Feb 18 18:40:04 1993 Received: from relay.rediris.es by optima.cs.arizona.edu (5.65c/15) via SMTP id AA08089; Thu, 18 Feb 1993 11:11:41 MST Received: from rediris.es by relay.rediris.es (PMDF #2585 ) id <01GUVI13AZB48WYO1F@relay.rediris.es>; Thu, 18 Feb 1993 18:41:59 GMT+1 Date: Thu, 18 Feb 1993 18:40:04 UTC+0200 From: lamq@a570.usal.es Subject: RTS abort: packet truncated To: info-sr@cs.arizona.edu Message-Id: <93-02-18-18:39> Content-Identifier: 93-02-18-18:39 Content-Transfer-Encoding: 7BIT X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=IRIS/ADMD=MENSATEX/C=ES/;SUUSAL CUASUBMM02181840040018] X400-Received: by mta iris-dcp in /PRMD=iris/ADMD=mensatex/C=es/; Relayed; Thu, 18 Feb 1993 18:40:41 UTC+0100 X400-Received: by /PRMD=IRIS/ADMD=MENSATEX/C=ES/; Relayed; Thu, 18 Feb 1993 18:40:04 UTC+0200 X400-Recipients: non-disclosure:; X400-Originator: lamq@a570.usal.es When I make a send to an operation in another virtual machine with large arrays as parameters, I obtain the message: [vm 1] RTS abort: packet truncated What is and who imposes the limit for a packet working with SR? Luis Antonio Miguel Quintales Universidad de Salamanca lamq@a570.usal.es From isc40002@nusunix3.nus.sg Tue Feb 23 08:53:12 1993 Received: from nuscc.nus.sg by optima.cs.arizona.edu (5.65c/15) via SMTP id AA01186; Mon, 22 Feb 1993 17:53:23 MST Received: from nusunix3.nus.sg by nuscc.nus.sg (5.65/1.34) id AA10142; Tue, 23 Feb 93 08:53:16 +0800 Received: by nusunix3.nus.sg (5.57/Ultrix3.0-C) id AA15842; Tue, 23 Feb 93 08:53:12 +0800 Date: Tue, 23 Feb 93 08:53:12 +0800 From: isc40002@nusunix3.nus.sg (CHEONG LAI HONG) Message-Id: <9302230053.AA15842@nusunix3.nus.sg> To: info-sr@cs.arizona.edu Hello, I wonder does capability variables slow down compilation? Or is it due to the file size, currently the a.out is over 0.2M, or are there any special reasons that will cause comilation from about 30 seconds jump to 4-10 minutes and currently it is 15 minutes? I have raised this qn before, but have not received any answer yet. Lai Hong From gmt Mon Feb 22 18:14:06 1993 Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA02438; Mon, 22 Feb 1993 18:14:07 MST Date: Mon, 22 Feb 1993 18:14:06 MST From: "Gregg Townsend" Message-Id: <199302230114.AA03532@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Mon, 22 Feb 1993 18:14:06 MST To: info-sr Subject: Re: capability variables slow compilation? Offhand, I can't think of any reason in particular why capability variables should slow down compilation. The only thing I've noticed is that on some HP systems, compilation time grows MUCH faster than linearly with the size of a procedure body or resource body. (p.s. if you've raised this question before, where did you raise 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 andrew@cs.chalmers.se Tue Feb 23 10:43:20 1993 Received: from animal.cs.chalmers.se by optima.cs.arizona.edu (5.65c/15) via SMTP id AA27906; Tue, 23 Feb 1993 02:43:22 MST Date: Tue, 23 Feb 93 10:43:20 +0100 From: Andrew Moran Message-Id: <9302230943.AA16085@animal.cs.chalmers.se> Received: from mumrik.cs.chalmers.se by animal.cs.chalmers.se (5.60+IDA/3.14+gl) id AA16085; Tue, 23 Feb 93 10:43:20 +0100 Received: from localhost by mumrik (5.60+IDA/3.14+gl) id AA15944; Tue, 23 Feb 93 10:43:19 +0100 To: info-sr@cs.arizona.edu ubject: Compiler Malfunction Date: Tue, 23 Feb 93 10:43:18 +0100 From: Andrew Moran X-Mts: smtp Hi guys, Given the following definitions: main.sr: resource main import sub_res body main () end main sub_res.sr: resource sub_res type CapType = rec (sr_cap : cap sub_res) optype SomeOpType () body sub_res () end sub_res I get this from the compiler: sr -s sub_res.sr sr -s main.sr sr -b main.sr COMPILER MALFUNCTION (?/0): segmentation violation make: *** [Interfaces/main.o] Error 1 This is obviously a much reduced version of the whole program I'm compiling. Both the type and optype definitions are required to produce the error. These definitions are used in the implementation of a parallel functional language that I wrote a couple of years in SR v1.1. I intend to convert it to SR v2.0, so you'll probably being hearing more from me on info-sr :-) Andy ---------- "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 Tue Feb 23 11:15:53 1993 Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA10013; Tue, 23 Feb 1993 11:15:54 MST Date: Tue, 23 Feb 1993 11:15:53 MST From: "Gregg Townsend" Message-Id: <199302231815.AA05053@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Tue, 23 Feb 1993 11:15:53 MST To: info-sr Subject: Re: Compiler Malfunctions The patch below, applied to sr/gmisc.c, fixes the segmentation fault. It will be included in the next release of SR. 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 ------------------------------------------------------------------------------ *** sr/gmisc.old Tue Feb 23 08:03:28 1993 --- sr/gmisc.c Tue Feb 23 08:53:59 1993 *************** *** 507,513 **** g = g->g_usig; /* signature of underlying resource */ s = g->g_sym; /* beginning of res's symtab entries */ for (o = s->s_next; o != NULL; o = o->s_next) ! if (o->s_kind == K_OP && o->s_imp == s) /* if op entry */ if (o->s_sig->g_type == T_ARRAY) nbytes += sizeof(Array) * fixedsize(o->s_sig, sizeof(Array)); --- 507,513 ---- g = g->g_usig; /* signature of underlying resource */ s = g->g_sym; /* beginning of res's symtab entries */ for (o = s->s_next; o != NULL; o = o->s_next) ! if (o->s_kind == K_OP && o->s_imp == s && o->s_sig) /* if op */ if (o->s_sig->g_type == T_ARRAY) nbytes += sizeof(Array) * fixedsize(o->s_sig, sizeof(Array)); From gmt Fri Mar 19 13:31:27 1993 Date: Fri, 19 Mar 1993 13:31:27 MST From: "Gregg Townsend" Message-Id: <199303192031.AA16385@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA16385; Fri, 19 Mar 1993 13:31:27 MST To: info-sr Subject: Announcing Version 2.1 of SR Version 2.1 of the SR programming language is now available, superseding version 2.0 of last August. Version 2.1 can be obtained: -- by anonymous FTP from the /sr directory on cs.arizona.edu -- by electronic mail: for details, send a "help" message to ftpmail@cs.arizona.edu or uunet!arizona!ftpmail -- on tape, cartridge or diskette: write to the address below for details SR (Synchronizing Resources) is a language for writing concurrent programs and is documented in "The SR Programming Language: Concurrency in Practice", by Gregory R. Andrews and Ronald A. Olsson (Benjamin/Cummings, 1993, ISBN 0-8053-0088-0). An overview of version 1 of the language and implementation appeared in the January, 1988, issue of ACM TOPLAS (10,1, 51-86). Version 2.1 adds tracing facilities, library support, an X-windows interface, new utilities, performance improvements, bug fixes, and support of Sun's Solaris 2.1 operating system. Other platforms include SunOS 4.1, SGI Iris, HP RISC, IBM RS/6000, Decstation, and Sequent Symmetry. For more information, send a message to sr-project@cs.arizona.edu. 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 gmt Fri Mar 19 13:41:41 1993 Date: Fri, 19 Mar 1993 13:41:41 MST From: "Gregg Townsend" Message-Id: <199303192041.AA17047@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA17047; Fri, 19 Mar 1993 13:41:41 MST To: info-sr Subject: Announcing Version 2.1 of SR [ This announcement a one-shot mailing to people who have shown a past interest in SR. Unless you're also on the Info-SR mailing list (see below), we won't be sending any further mail. If you're on the list, you've already seen this. ] Version 2.1 of the SR programming language is now available, superseding version 2.0 of last August. Version 2.1 can be obtained: -- by anonymous FTP from the /sr directory on cs.arizona.edu -- by electronic mail: for details, send a "help" message to ftpmail@cs.arizona.edu or uunet!arizona!ftpmail -- on tape, cartridge or diskette: write to the address below for details SR (Synchronizing Resources) is a language for writing concurrent programs and is documented in "The SR Programming Language: Concurrency in Practice", by Gregory R. Andrews and Ronald A. Olsson (Benjamin/Cummings, 1993, ISBN 0-8053-0088-0). An overview of version 1 of the language and implementation appeared in the January, 1988, issue of ACM TOPLAS (10,1, 51-86). Version 2.1 adds tracing facilities, library support, an X-windows interface, new utilities, performance improvements, bug fixes, and support of Sun's Solaris 2.1 operating system. Other platforms include SunOS 4.1, SGI Iris, HP RISC, IBM RS/6000, Decstation, and Sequent Symmetry. For more information about SR, send a message to sr-project@cs.arizona.edu. To join the Info-SR mailing list, a mailing list for discussing SR issues, send your email address to info-sr-request@cs.arizona.edu. 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 johnd@ted.cs.uidaho.edu Thu Apr 8 14:55:03 1993 Received: from ted.cs.uidaho.edu (puffin.cs.uidaho.edu) by optima.cs.arizona.edu (5.65c/15) via SMTP id AA24010; Thu, 8 Apr 1993 14:55:10 MST Received: by ted.cs.uidaho.edu (16.6/1.34) id AA06402; Thu, 8 Apr 93 14:55:06 -0700 From: johnd@ted.cs.uidaho.edu (John Dickinson) Message-Id: <9304082155.AA06402@ted.cs.uidaho.edu> Subject: Vacancy-UofIdaho-CS To: info-sr@cs.arizona.edu Date: Thu, 8 Apr 93 14:55:03 PDT Mailer: Elm [revision: 66.25] VACANCY ANNOUNCEMENT University of Idaho Department of Computer Science The Department of Computer Science at the University of Idaho invites applications for a tenure-track faculty position at the associate or assistant professor level. The Department of Computer Science is in the College of Engineering and one of the college's highest priorities is to build a strong research program in computer science. Candidates should have a specialization involving the Theory of Programming Languages, but candidates in the areas of Formal Methods or Software Engineering will also be considered. Qualifications for this position include an earned PhD in Computer Science or a closely related field, US citizenship or lawfully authorized alien worker status, teaching and research ability, potential for establishing a strong research program (research experience is preferred), with specialization in the theory of programming languages, formal methods, or software engineering. Successful candidates are expected to pursue an active research program, perform graduate and undergraduate teaching, and supervise graduate students. Successful applicants will be expected to publish, obtain grants, contribute to the quality growth of the graduate program, and participate in the delivery and development of the quality undergraduate program. The department has 13 tenure-track faculty and 1 jointly appointed faculty (including 2 women faculty), approximately 200 undergraduate majors, and 30 graduate students. The BS and MS degrees are currently offered and we expect approval to offer the PhD degree in computer science next year. The department has established research laboratories for software engineering and formal methods and the department is associated with the NASA Microelectronics Research Center and the DOT National Center for Advanced Transportation Technology at the University of Idaho. Washington State University is located just 8 miles away and cooperative programs are available with their faculty. The University of Idaho is situated in the northern panhandle of Idaho (about 90 miles south of Spokane, WA), close to spectacular lakes, wilderness, and skiing. The Computer Science department has approximately 50 Unix workstations (HP, Apollo, and DEC) which are networked to Internet. Numerous other college and university workstations and computer laboratories are available for faculty and student use. Over the past three years, Hewlett-Packard has donated $1,000,000 in computer equipment to the Department of Computer Science to further enhance the research and teaching capability of the faculty. Applicants must submit a curriculum vitae and three letters of reference to John Dickinson, Search Committee Chair, Department of Computer Science, University of Idaho, Moscow, ID 83844-1011 (email: search93@cs.uidaho.edu). Applicants must include a statement about their citizenship and/or visa status. Complete applications will be accepted until April 23, 1993 or until suitable candidates are selected. The University of Idaho is an EO/AA employer and educational institution and specifically invites applications from women and minorities. From dinkar@whitehouse.eecs.uic.edu Wed Apr 21 11:18:03 1993 Received: from whitehouse.eecs.uic.edu by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA14835; Wed, 21 Apr 1993 09:16:24 MST Received: by whitehouse.eecs.uic.edu id AA19160 (5.64+/IDA-1.3.4 for info-sr@cs.arizona.edu); Wed, 21 Apr 93 11:18:03 -0500 Date: Wed, 21 Apr 93 11:18:03 -0500 From: Karumuri Dinkar Message-Id: <9304211618.AA19160@whitehouse.eecs.uic.edu> To: info-sr@cs.arizona.edu Hai, I would like to join the discussion group of SR. My name is Dinkar Karumuri e:mail dinkar@bert.eecs.uic.edu From dragon@ossi.com Wed May 19 14:06:51 1993 Received: from rara.ossi.com by optima.cs.arizona.edu (5.65c/15) via SMTP id AA06876; Wed, 19 May 1993 14:05:59 MST Received: from tao.ossi.com (tao.ossi.com [192.240.2.32]) by rara.ossi.com (ALPHA-6.54/6.27) id OAA25673; Wed, 19 May 1993 14:05:56 -0700 Message-Id: <2294.9305192106@tao.ossi.com> Received: from localhost by tao.ossi.com; Wed, 19 May 93 14:06:51 PDT To: info-sr@cs.arizona.edu Cc: dragon Subject: Bug Report Date: Wed, 19 May 93 14:06:51 PDT From: dragon@ossi.com I've found a bug in sr's handling of the "%x" format string in scanf(). I am using version 2.1 dated March 1993 This bug exhibits itself by refusing to accept the characters 'a'-'f' or 'A'-'F' as the last character of a hexadecimal input number. For instance a format of "%02" would accept "A0" but not "0A" I changed rts/scan.c line 621 - return 0 should be ret = 1 So far the fix seems to work OK. Thanks to everyone who contributed to this fine language. -Norman Morse From shartley@king.mcs.drexel.edu Tue Jun 22 14:38:27 1993 Received: from mcs.drexel.edu (king.mcs.drexel.edu) by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA11413; Tue, 22 Jun 1993 11:38:41 MST Received: by mcs.drexel.edu (4.1/SMI-4.0) id AA21091; Tue, 22 Jun 93 14:38:27 EDT Date: Tue, 22 Jun 93 14:38:27 EDT From: shartley@king.mcs.drexel.edu (Stephen J. Hartley) Message-Id: <9306221838.AA21091@mcs.drexel.edu> To: info-sr@cs.arizona.edu Subject: deadlock in decentralized dining philosophers (chapter 13) Chapter 13 of the "SR Programming Language" book by Andrews and Olsson contains the decentralized version of the dining philosophers (page 200). It is based on "The Drinking Philosophers Problem" article (Chandy and Misra, ACM Trans. Prog. Lang. & Sys., October 1984). The algorithm is supposed to be deadlock free. However it looks to me like the following sequence of events will lead to deadlock: initial configuration: no forks dirty, phil 1 has both forks, phil 2 thru 4 have right fork but not left, phil 5 has neither, all phils thinking phil 5 get H, asks for its R fork from phil 1, gets it, asks phil 4 for L fork, while that message is in transit.... phil 4 gets H, has R fork, asks phil 3 for L fork, while that message is in transit...... phil 3 gets H, has R fork, asks phil 2 for L fork, while that message is in transit...... phil 2 gets H, has R fork, asks phil 1 for L fork, while that message is in transit...... phil 1 gets H, has R fork, asks phil 5 for L fork that it gave up now all the messages arrive, all phils are hungry, each holding a clean fork (its right one) and asking for its left fork I have constructed a version of the program that delays some of the messages enough so that the above actually happens in a run of the program. See the following script output. If I change the state of both the forks initially allocated to philosopher 1 so they are (artificially) dirty at the beginning of the program, then there is no deadlock. In the meantime, I will hunt down a copy of the drinking philosophers article.... -- Stephen J. Hartley, Visiting Assistant Professor Math and Computer Science, Drexel University, Philadelphia, PA 19104 office (215) 895-2678, fax (215) 895-4999, e-mail shartley@mcs.drexel.edu -- Script started on Tue Jun 22 14:14:28 1993 % cat dp.sr resource Philosopher import Servant body Philosopher(myservant : cap Servant; id, thinking, eating: int) process phil do true -> nap(thinking); write(age(), "philosopher", id, "is hungry") myservant.getforks(); nap(eating); myservant.relforks() od end phil end Philosopher resource Servant op getforks(), relforks() op needL(), needR(), passL(), passR() op links(l, r : cap Servant) op forks(haveL, dirtyL, haveR, dirtyR : bool) body Servant(id : int) var l, r : cap Servant var haveL, dirtyL, haveR, dirtyR : bool op hungry(), eat() proc getforks() send hungry(); receive eat() end process server receive links(l, r) receive forks(haveL, dirtyL, haveR, dirtyR) do true-> in hungry() -> if ~haveR -> send r.needL() [] else -> write(age(), "philosopher", id, "has right fork") fi if ~haveL -> send l.needR() [] else -> write(age(), "philosopher", id, "has left fork") fi do ~(haveL & haveR) -> in passL() -> haveL := true; dirtyL := false write(age(), "philosopher", id, "got left fork") [] passR() -> haveR := true; dirtyR := false write(age(), "philosopher", id, "got right fork") [] needR() st dirtyR -> haveR := false; dirtyR := false send r.passL(); send r.needL() write(age(), "philosopher", id, "sends dirty right fork") [] needL() st dirtyL -> haveL := false; dirtyL := false send l.passR(); send l.needR() write(age(), "philosopher", id, "sends dirty left fork") ni od write(age(), "philosopher", id, "has both forks") send eat(); dirtyL := true; dirtyR := true receive relforks() write(age(), "philosopher", id, "is finished eating") [] needR() -> haveR := false; dirtyR := false; send r.passL() write(age(), "philosopher", id, "sends right fork") [] needL() -> haveL := false; dirtyL := false; send l.passR() write(age(), "philosopher", id, "sends left fork") ni od end server end Servant resource Main import Philosopher, Servant body Main() var n := 5; getarg(1, n) var s[1:n] : cap Servant; var p[1:n] : cap Philosopher var think[1:n] : int := ([n] 5); var eat[1:n] : int := ([n] 2) fa i := 1 to n -> getarg(2*i, think[i]); getarg(2*i+1, eat[i]) af fa i := 1 to n -> s[i] := create Servant(i) create Philosopher(s[i], i, 1000*think[i], 1000*eat[i]) af printf("%4d philosophers created; think, eat times in seconds:\n", n) fa i := 1 to n -> printf("%4d", think[i]) af; printf("\n") fa i := 1 to n -> printf("%4d", eat[i]) af; printf("\n") fa i := 1 to n -> send s[i].links(s[((i-2) mod n)+1], s[(i mod n)+1]) af send s[1].forks(true, false, true, false) fa i := 2 to n-1 -> send s[i].forks(false, false, true, false) af send s[n].forks(false, false, false, false) end Main % sr dp.sr % ./a.out 5 7 2 5 2 5 2 5 2 5 2 5 philosophers created; think, eat times in seconds: 7 5 5 5 5 2 2 2 2 2 5056 philosopher 2 is hungry 5060 philosopher 2 has right fork 5061 philosopher 1 sends right fork 5063 philosopher 2 got left fork 5064 philosopher 2 has both forks 5065 philosopher 3 is hungry 5067 philosopher 3 has right fork 5086 philosopher 4 is hungry 5089 philosopher 4 has right fork 5096 philosopher 5 is hungry 5099 philosopher 1 sends left fork 5100 philosopher 5 got right fork 7036 philosopher 1 is hungry 7076 philosopher 2 is finished eating 7079 philosopher 2 sends right fork 7081 philosopher 2 sends left fork 7082 philosopher 3 got left fork 7083 philosopher 3 has both forks 7084 philosopher 1 got right fork 9087 philosopher 3 is finished eating 9090 philosopher 3 sends right fork 9092 philosopher 4 got left fork 9093 philosopher 4 has both forks 11097 philosopher 4 is finished eating 11101 philosopher 4 sends right fork 11102 philosopher 5 got left fork 11103 philosopher 5 has both forks 12086 philosopher 2 is hungry 12090 philosopher 3 sends left fork 12091 philosopher 2 got right fork 13106 philosopher 5 is finished eating 13109 philosopher 5 sends right fork 13111 philosopher 1 got left fork 13112 philosopher 1 has both forks 14096 philosopher 3 is hungry 14100 philosopher 4 sends left fork 14101 philosopher 3 got right fork 15116 philosopher 1 is finished eating 15120 philosopher 1 sends right fork 15121 philosopher 2 got left fork 15122 philosopher 2 has both forks 16106 philosopher 4 is hungry 16110 philosopher 5 sends left fork 16112 philosopher 4 got right fork 17126 philosopher 2 is finished eating 17130 philosopher 2 sends right fork 17131 philosopher 3 got left fork 17132 philosopher 3 has both forks 18116 philosopher 5 is hungry 18120 philosopher 1 sends left fork 18121 philosopher 5 got right fork 19137 philosopher 3 is finished eating 19140 philosopher 3 sends right fork 19142 philosopher 4 got left fork 19143 philosopher 4 has both forks 21146 philosopher 4 is finished eating 21149 philosopher 4 sends right fork 21151 philosopher 5 got left fork 21152 philosopher 5 has both forks 22126 philosopher 1 is hungry 22130 philosopher 2 sends left fork 22131 philosopher 1 got right fork 22132 philosopher 2 is hungry 22134 philosopher 3 sends left fork 22135 philosopher 2 got right fork 23157 philosopher 5 is finished eating 23160 philosopher 5 sends right fork 23161 philosopher 1 got left fork 23163 philosopher 1 has both forks 24146 philosopher 3 is hungry 24150 philosopher 4 sends left fork 24151 philosopher 3 got right fork 25166 philosopher 1 is finished eating 25170 philosopher 1 sends right fork 25171 philosopher 2 got left fork 25172 philosopher 2 has both forks 26156 philosopher 4 is hungry 26172 philosopher 5 sends left fork 26174 philosopher 4 got right fork 27177 philosopher 2 is finished eating 27181 philosopher 2 sends right fork 27182 philosopher 3 got left fork 27183 philosopher 3 has both forks 28166 philosopher 5 is hungry 28171 philosopher 1 sends left fork 28172 philosopher 5 got right fork 29186 philosopher 3 is finished eating 29190 philosopher 3 sends right fork 29191 philosopher 4 got left fork 29192 philosopher 4 has both forks 31197 philosopher 4 is finished eating 31200 philosopher 4 sends right fork 31201 philosopher 5 got left fork 31202 philosopher 5 has both forks ^C % cat dp_delay_needR.sr resource Philosopher import Servant body Philosopher(myservant : cap Servant; id, thinking, eating: int) process phil do true -> nap(thinking); write(age(), "philosopher", id, "is hungry") myservant.getforks(); nap(eating); myservant.relforks() od end phil end Philosopher resource Servant op getforks(), relforks() op needL(), needR(), passL(), passR() op links(l, r : cap Servant) op forks(haveL, dirtyL, haveR, dirtyR : bool) body Servant(id : int) var l, r : cap Servant var haveL, dirtyL, haveR, dirtyR : bool op hungry(), eat() op delay_needR() ### proc getforks() send hungry(); receive eat() end process delayed_send ### in delay_needR() -> nap(10000); send l.needR() ### ni ### end delayed_send ### process server receive links(l, r) receive forks(haveL, dirtyL, haveR, dirtyR) do true-> in hungry() -> if ~haveR -> send r.needL() [] else -> write(age(), "philosopher", id, "has right fork") fi # if ~haveL -> send l.needR() if ~haveL -> send delay_needR() ### [] else -> write(age(), "philosopher", id, "has left fork") fi do ~(haveL & haveR) -> in passL() -> haveL := true; dirtyL := false write(age(), "philosopher", id, "got left fork") [] passR() -> haveR := true; dirtyR := false write(age(), "philosopher", id, "got right fork") [] needR() st dirtyR -> haveR := false; dirtyR := false send r.passL(); send r.needL() write(age(), "philosopher", id, "sends dirty right fork") [] needL() st dirtyL -> haveL := false; dirtyL := false send l.passR(); send l.needR() write(age(), "philosopher", id, "sends dirty left fork") ni od write(age(), "philosopher", id, "has both forks") send eat(); dirtyL := true; dirtyR := true receive relforks() write(age(), "philosopher", id, "is finished eating") [] needR() -> haveR := false; dirtyR := false; send r.passL() write(age(), "philosopher", id, "sends right fork") [] needL() -> haveL := false; dirtyL := false; send l.passR() write(age(), "philosopher", id, "sends left fork") ni od end server end Servant resource Main import Philosopher, Servant body Main() var n := 5; getarg(1, n) var s[1:n] : cap Servant; var p[1:n] : cap Philosopher var think[1:n] : int := ([n] 5); var eat[1:n] : int := ([n] 2) fa i := 1 to n -> getarg(2*i, think[i]); getarg(2*i+1, eat[i]) af fa i := 1 to n -> s[i] := create Servant(i) create Philosopher(s[i], i, 1000*think[i], 1000*eat[i]) af printf("%4d philosophers created; think, eat times in seconds:\n", n) fa i := 1 to n -> printf("%4d", think[i]) af; printf("\n") fa i := 1 to n -> printf("%4d", eat[i]) af; printf("\n") fa i := 1 to n -> send s[i].links(s[((i-2) mod n)+1], s[(i mod n)+1]) af send s[1].forks(true, false, true, false) fa i := 2 to n-1 -> send s[i].forks(false, false, true, false) af send s[n].forks(false, false, false, false) end Main % sr dp_delay_needR.sr % ./a.out 5 7 2 5 2 5 2 5 2 5 2 5 philosophers created; think, eat times in seconds: 7 5 5 5 5 2 2 2 2 2 5086 philosopher 2 is hungry 5090 philosopher 2 has right fork 5115 philosopher 3 is hungry 5118 philosopher 3 has right fork 5146 philosopher 4 is hungry 5149 philosopher 4 has right fork 5165 philosopher 5 is hungry 5168 philosopher 1 sends left fork 5170 philosopher 5 got right fork 7057 philosopher 1 is hungry 7086 philosopher 1 has right fork RTS warning: blocked process: Servant.getforks : file dp_delay_needR.sr, line 24 RTS warning: blocked process: Servant.server : file dp_delay_needR.sr, line 45 RTS warning: blocked process: Servant.getforks : file dp_delay_needR.sr, line 24 RTS warning: blocked process: Servant.server : file dp_delay_needR.sr, line 45 RTS warning: blocked process: Servant.getforks : file dp_delay_needR.sr, line 24 RTS warning: blocked process: Servant.server : file dp_delay_needR.sr, line 45 RTS warning: blocked process: Servant.getforks : file dp_delay_needR.sr, line 24 RTS warning: blocked process: Servant.server : file dp_delay_needR.sr, line 45 RTS warning: blocked process: Servant.getforks : file dp_delay_needR.sr, line 24 RTS warning: blocked process: Servant.server : file dp_delay_needR.sr, line 45 % exit Now edit the above program so that the line send s[1].forks(true, false, true, false) is changed to send s[1].forks(true, true, true, true) and there is no deadlock. % ./a.out 5 7 2 5 2 5 2 5 2 5 2 5 philosophers created; think, eat times in seconds: 7 5 5 5 5 2 2 2 2 2 5059 philosopher 2 is hungry 5063 philosopher 2 has right fork 5079 philosopher 3 is hungry 5081 philosopher 3 has right fork 5099 philosopher 4 is hungry 5101 philosopher 4 has right fork 5119 philosopher 5 is hungry 5122 philosopher 1 sends left fork 5124 philosopher 5 got right fork 7039 philosopher 1 is hungry 7043 philosopher 1 has right fork 15070 philosopher 1 sends dirty right fork 15074 philosopher 2 got left fork 15076 philosopher 2 has both forks 17079 philosopher 2 is finished eating 17082 philosopher 2 sends left fork 17084 philosopher 2 sends right fork 17087 philosopher 1 got right fork 17089 philosopher 3 got left fork 17091 philosopher 3 has both forks 19099 philosopher 3 is finished eating 19102 philosopher 3 sends right fork 19105 philosopher 4 got left fork 19107 philosopher 4 has both forks 21110 philosopher 4 is finished eating 21113 philosopher 4 sends right fork 21115 philosopher 5 got left fork 21117 philosopher 5 has both forks 22089 philosopher 2 is hungry 22092 philosopher 3 sends left fork 22095 philosopher 2 got right fork 23119 philosopher 5 is finished eating 23122 philosopher 5 sends right fork 23125 philosopher 1 got left fork 23127 philosopher 1 has both forks ^C % From greg Tue Jun 22 15:32:45 1993 Received: from paloverde.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA28020; Tue, 22 Jun 1993 15:32:47 MST Date: Tue, 22 Jun 1993 15:32:45 MST From: "Greg Andrews" Message-Id: <199306222232.AA09951@paloverde.cs.arizona.edu> Received: by paloverde.cs.arizona.edu; Tue, 22 Jun 1993 15:32:45 MST To: info-sr@cs.arizona.edu, shartley@king.mcs.drexel.edu Subject: Re: deadlock in decentralized dining philosophers (chapter 13) You are quite right. Our mistake. Thanks for catching the problem and coming up with a correct solution. Greg Andrews From benson@cs.ucdavis.edu Thu Jun 24 15:37:12 1993 Received: from elysium.cs.ucdavis.edu by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA27510; Thu, 24 Jun 1993 15:37:16 MST Received: from localhost.cs.ucdavis.edu by elysium.cs.ucdavis.edu (5.65/UCD.CS.2.3) id AA10629; Thu, 24 Jun 1993 15:37:13 -0700 Message-Id: <9306242237.AA10629@elysium.cs.ucdavis.edu> To: info-sr@cs.arizona.edu Subject: i386 context switch code Date: Thu, 24 Jun 93 15:37:12 -0700 From: benson@cs.ucdavis.edu X-Mts: smtp I am porting SR to Linux (a i386 UNIX-like OS) and I have come to the context switch code. I attemped to use the "i386.s" file. The comments say that it might work for other 386 machines. Well, as you can guess it isn't working. I can get it to assemble, but the cstest program fails: sleep:/1/home/benson/pkg/sr/csw# cstest running context switch test, arch = Intel 386 creating stack for foo creating stack for bar creating stack for baz creating stack for boo creating stack for stir csw: stack overflow sleep:/1/home/benson/pkg/sr/csw# I am prepared to figure out what is going on (i.e. check the calling seqeunces, etc.) , but I first wanted to make sure that it hasn't been done yet. In particular, has anyone been able to use the i386.s code on another 386 machine besides the Sequent Symmetry? Any help would be appreciated. Note: In getting the i386.s code to assemble I had to modify the file a bit. The Makefile in the csw directory uses the following: $(CC) $(CFLAGS) -E asm.c | sed -e '/^ *$$/d' -e '/^#/'d >asm.s I am using gcc and the defines: #define MAGIC 79797979 /* any unlikely long integer */ #define RSIZE 16 /* size of register save area */ do not substitute correctly. For example: cmpl $MAGIC,(%eax) /* catch earlier overflow (maybe) */ Does not produce: cmpl $79797979,(%eax) Because the gcc preprocessor can't match $MAGIC. Just to get it working I substituted the values by hand. Thanks Greg Benson Research Assistant Department of Computer Science University of California, Davis benson@cs.ucdavis.edu From sompop@wizard.etsu.edu Sun Jul 25 15:59:34 1993 Received: from wizard.etsu.edu by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA09543; Sun, 25 Jul 1993 14:17:51 MST Received: by wizard.etsu.edu (16.6/16.2) id AA04360; Sun, 25 Jul 93 16:21:35 -0500 Date: Sun, 25 Jul 1993 15:59:34 -0500 (CDT) From: Sompop Wongwacharadumrong Subject: New kid in town To: SR Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! everybody I'm a newbie of SR and need help from you guys. I know that I should read the SR materials before I could do something. The problem is that I cannot find the book of Andrews & Olsson in my city. Please tell me if you guys know how to get the SR book by mail. BTW, if you have any suggestions for a newbie like me, please let me know. Thank ################################################ ## Sompop Wongwacharadumrong ## ## Tel: (903) 886-4768 ## ## e-mail: sompop@wizard.etsu.edu ## ################################################ From olsson@cs.ucdavis.edu Wed Aug 18 17:23:02 1993 Received: from ivy.cs.ucdavis.edu by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA09909; Wed, 18 Aug 1993 17:23:05 MST Received: by ivy.cs.ucdavis.edu (5.65/UCD.CS.2.3) id AA18603; Wed, 18 Aug 1993 17:23:02 -0700 Date: Wed, 18 Aug 1993 17:23:02 -0700 From: olsson@cs.ucdavis.edu (Ron Olsson) Message-Id: <9308190023.AA18603@ivy.cs.ucdavis.edu> To: info-sr@cs.arizona.edu Subject: SR on Alpha? Has anyone ported, or is anyone in the process of porting, SR to the DEC Alpha? From kdchung@hyowon.pusan.ac.kr Sat Aug 21 14:38:09 1993 Received: from garam.kreonet.re.kr ([134.75.30.11]) by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA09618; Fri, 20 Aug 1993 22:35:59 MST Received: from hyowon.pusan.ac.kr ([164.125.9.3]) by garam.kreonet.re.kr (4.1/GARAM-MX-1.0) id AA06094; Sat, 21 Aug 93 14:36:57 KDT Received: by hyowon.pusan.ac.kr (AIX 3.2/UCB 5.64/hyowon-0.1) id AA18232; Sat, 21 Aug 1993 14:38:09 +0900 Date: Sat, 21 Aug 1993 14:38:09 +0900 From: kdchung@hyowon.pusan.ac.kr (Kidong Chung ) Message-Id: <9308210538.AA18232@hyowon.pusan.ac.kr> To: info-sr@cs.arizona.edu Subject: From Chung in South Korea Thank you for your message! My name and address are as follow: Prof. Ki Dong Chung Depart. of Computer Science Pusan National Univ. Pusan, Korea, 609-735 e-mail address : kdchung@hyowon.pusan.ac.kr ------------------------------------------ And I am going to teach Concurrent Programming, especially SR, using the Andrews' book. Do you have any comment or advice? They are all graduate students. Do you have any materials? Thanks! Bye! From kdchung@hyowon.pusan.ac.kr Sat Aug 21 15:09:51 1993 Received: from garam.kreonet.re.kr ([134.75.30.11]) by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA10713; Fri, 20 Aug 1993 23:07:39 MST Received: from hyowon.pusan.ac.kr ([164.125.9.3]) by garam.kreonet.re.kr (4.1/GARAM-MX-1.0) id AA06419; Sat, 21 Aug 93 15:08:39 KDT Received: by hyowon.pusan.ac.kr (AIX 3.2/UCB 5.64/hyowon-0.1) id AA17050; Sat, 21 Aug 1993 15:09:51 +0900 Date: Sat, 21 Aug 1993 15:09:51 +0900 From: kdchung@hyowon.pusan.ac.kr (Kidong Chung ) Message-Id: <9308210609.AA17050@hyowon.pusan.ac.kr> To: info-sr@cs.arizona.edu Subject: From Chung in South Korea Hi! I am very happy to hear that my name is put on the list. My name and address are as follow: Prof. Ki Dong Chung Depart. of Computer Science Pusan National Univ. Pusan, Korea, 609-735 ----------------------------------- And I am goint to teach Concurrent Programming, especially SR, using the Andrews' book. Do you have any comment or advice , or materials? Thanks! Chung From kdchung@hyowon.pusan.ac.kr Tue Aug 24 11:08:36 1993 Received: from garam.kreonet.re.kr ([134.75.30.11]) by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA00191; Mon, 23 Aug 1993 19:06:55 MST Received: from hyowon.pusan.ac.kr ([164.125.9.3]) by garam.kreonet.re.kr (4.1/GARAM-MX-1.0) id AA10930; Tue, 24 Aug 93 11:07:56 KDT Received: by hyowon.pusan.ac.kr (AIX 3.2/UCB 5.64/hyowon-0.1) id AA28672; Tue, 24 Aug 1993 11:08:36 +0900 Date: Tue, 24 Aug 1993 11:08:36 +0900 From: kdchung@hyowon.pusan.ac.kr (Kidong Chung ) Message-Id: <9308240208.AA28672@hyowon.pusan.ac.kr> To: info-sr@cs.arizona.edu Subject: From Chung in Korea Some kind profeesor told me that he taught O.S course and used SR, and one of his student implemented SR on PC. Can I get his address again? Thanks! Bye! From g9311114@cs.uow.edu.au Wed Aug 25 13:33:03 1993 Received: from wraith.cs.uow.edu.au by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA15968; Tue, 24 Aug 1993 20:33:21 MST Received: by wraith.cs.uow.edu.au (5.65c/IDA-1.4.4); id AA08449; Wed, 25 Aug 1993 13:33:04 +1000 (from g9311114@cs.uow.edu.au for info-sr@cs.arizona.edu) From: Rahul Gupte Message-Id: <199308250333.AA08449@wraith.cs.uow.edu.au> Subject: request for help To: info-sr@cs.arizona.edu Date: Wed, 25 Aug 1993 13:33:03 +1000 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2232 Forwarded message: From MAILER-DAEMON Wed Aug 25 13:30:44 1993 +1000 Date: Wed, 25 Aug 1993 13:30:09 +1000 From: Mail Delivery Subsystem Message-Id: <199308250330.AA07948@wraith.cs.uow.edu.au> To: g9311114 Cc: steve Subject: Returned mail: User unknown ----- Transcript of session follows ----- While talking to optima.CS.Arizona.EDU: >>> RCPT To: <<< 550 ... User unknown 550 inf0-sr-errors@cs.arizona.edu... User unknown ----- Unsent message follows ----- Received: by wraith.cs.uow.edu.au (5.65c/IDA-1.4.4); id AA07940; Wed, 25 Aug 1993 13:30:09 +1000 (from g9311114 for inf0-sr-errors@cs.arizona.edu) From: Rahul Gupte Message-Id: <199308250330.AA07940@wraith.cs.uow.edu.au> Subject: help wanted To: inf0-sr-errors@cs.arizona.edu Date: Wed, 25 Aug 1993 13:30:07 +1000 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1233 On compiling the following SR program I get an error saying 'myprocess' is an unidentified identifier. Isn't myprocess a special function provided in SR that enables a process in a process family to determine its index ? ------------------------------------------------------ resource Primes() const NEWLINE:=char(10); var sieve_size[2:11]:int ; op candidate[sieve_size](c:int){send}; var limit:int; process Starter var n:int; writes("type in a limit up to 31*31=961: "); read(limit) write(NEWLINE); write(2); n:=3; do n <= limit -> send candidate[1](n); n:=n+2; od end procedure Sieve(sieve_size) var p,m,mp,pn:int; in candidate(c) -> p:=c; mp:=c; m:=c; ni; write(p); do myprocess < ub(Sieve) and m <= limit -> in candidate(c)-> m:=c ni; do m > mp -> mp:=mp+p od; if m = mp -> skip []m < mp -> send candidate[myprocess+1](m) fi []myprocess = ub(Sieve) and m <=limit -> in candidate(c) -> mp:=c ni; if mp < p*p -> writes(mp) []else -> skip fi od end Sieve end Primes From olsson@cs.ucdavis.edu Tue Aug 24 20:56:39 1993 Received: from ivy.cs.ucdavis.edu by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA17146; Tue, 24 Aug 1993 21:05:32 MST Received: by ivy.cs.ucdavis.edu (5.65/UCD.CS.2.3) id AA19934; Tue, 24 Aug 1993 20:56:39 -0700 Date: Tue, 24 Aug 1993 20:56:39 -0700 From: olsson@cs.ucdavis.edu (Ron Olsson) Message-Id: <9308250356.AA19934@ivy.cs.ucdavis.edu> To: g9311114@cs.uow.edu.au Cc: info-sr@cs.arizona.edu In-Reply-To: <199308250333.AA08449@wraith.cs.uow.edu.au> (message from Rahul Gupte on Wed, 25 Aug 1993 13:33:03 +1000 (EST)) Subject: request for help From: Rahul Gupte Date: Wed, 25 Aug 1993 13:33:03 +1000 (EST) On compiling the following SR program I get an error saying 'myprocess' is an unidentified identifier. Isn't myprocess a special function provided in SR that enables a process in a process family to determine its index ? No. (Although I think it was years ago in version 0 of SR.) Chapter 7 of the SR book, as well as some of the sample programs in the examples directory, shows how to get process families. From liupeng@cs.tamu.edu Wed Aug 25 00:15:02 1993 Received: from clavin.cs.tamu.edu by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA20066; Tue, 24 Aug 1993 22:19:38 MST Received: from cs.tamu.edu (sparc40.cs.tamu.edu) by clavin.cs.tamu.edu (AA15011); Wed, 25 Aug 93 00:15:02 CDT Date: Wed, 25 Aug 93 00:15:02 CDT From: liupeng@cs.tamu.edu (Peng Liu) Message-Id: <9308250515.AA15011@clavin.cs.tamu.edu> To: info-sr@cs.arizona.edu signoff info-sr From gmt Tue Aug 31 08:17:14 1993 Received: from owl.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA26459; Tue, 31 Aug 1993 08:17:16 MST Date: Tue, 31 Aug 1993 08:17:14 MST From: "Gregg Townsend" Message-Id: <199308311517.AA02224@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Tue, 31 Aug 1993 08:17:14 MST To: info-sr Subject: Announcing Version 2.2 of SR Version 2.2 of the SR programming language is now available, superseding version 2.1 of last March. Version 2.2 can be obtained: -- by anonymous FTP from the /sr directory on cs.arizona.edu -- by electronic mail: for details, send a "help" message to ftpmail@cs.arizona.edu or uunet!arizona!ftpmail -- on tape, cartridge or diskette: write to the address below for details SR (Synchronizing Resources) is a language for writing concurrent programs and is documented in "The SR Programming Language: Concurrency in Practice", by Gregory R. Andrews and Ronald A. Olsson (Benjamin/Cummings, 1993, ISBN 0-8053-0088-0). An overview of version 1 of the language and implementation appeared in the January, 1988, issue of ACM TOPLAS (10,1, 51-86). Version 2.2 adds dynamic operations, input from capabilities, library support (for SRWin) in srm, and true multiprocessing under Sun Solaris 2.2 as well as the SGI Iris and Sequent Symmetry. Other platforms include SunOS 4.1, HP RISC, and Dec MIPS. For more information, send a message to sr-project@cs.arizona.edu. 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 gmt Tue Aug 31 09:45:31 1993 Date: Tue, 31 Aug 1993 09:45:31 MST From: "Gregg Townsend" Message-Id: <199308311645.AA02257@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA02257; Tue, 31 Aug 1993 09:45:31 MST To: info-sr Subject: Announcing Version 2.2 of SR [ This announcement a one-shot mailing to people who have shown a recent interest in SR. Unless you're also on the Info-SR mailing list (see below), we won't be sending any further mail. If you're on the list, you've already seen this. ] Version 2.2 of the SR programming language is now available, superseding version 2.1 of last March. Version 2.2 can be obtained: -- by anonymous FTP from the /sr directory on cs.arizona.edu -- by electronic mail: for details, send a "help" message to ftpmail@cs.arizona.edu or uunet!arizona!ftpmail -- on tape, cartridge or diskette: write to the address below for details SR (Synchronizing Resources) is a language for writing concurrent programs and is documented in "The SR Programming Language: Concurrency in Practice", by Gregory R. Andrews and Ronald A. Olsson (Benjamin/Cummings, 1993, ISBN 0-8053-0088-0). An overview of version 1 of the language and implementation appeared in the January, 1988, issue of ACM TOPLAS (10,1, 51-86). Version 2.2 adds dynamic operations, input from capabilities, library support (for SRWin) in srm, and true multiprocessing under Sun Solaris 2.2 as well as the SGI Iris and Sequent Symmetry. Other platforms include SunOS 4.1, HP RISC, and Dec MIPS. For more information about SR, send a message to sr-project@cs.arizona.edu. To join the Info-SR mailing list, a mailing list for discussing SR issues, send your email address to info-sr-request@cs.arizona.edu. 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 andrew@cs.chalmers.se Thu Sep 2 19:05:25 1993 Received: from animal.cs.chalmers.se by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA24791; Thu, 2 Sep 1993 10:05:31 MST Message-Id: <9309021705.AA20461@animal.cs.chalmers.se> Received: from localhost.cs.chalmers.se by animal.cs.chalmers.se (5.60+IDA/3.14+gl) id AA20461; Thu, 2 Sep 93 19:05:27 +0200 To: info-sr@cs.arizona.edu Subject: Bug report (vague) for v2.2 Date: Thu, 02 Sep 1993 19:05:25 +0200 From: Andrew Moran I'm converting an old program to use dynamic operations, and they're just right for what I want to do. I've tested the code using them in isolation from my other stuff and it works fine. However, when I come to incorporate it all again, I run into trouble. The subject line says it's a vague bug report because I haven't managed to whittle down my code to a size more suitable mailing you guys. Here's the problem: a parent resource invokes the operation defined second in a child, but the operation defined _third_ is invoked instead. This operation has different arguments of course and this eventually leads to a bus error. I discovered this was the case by scanning the trace information (very neat utility BTW). A bit of fun with dbx yields the following: (dbx) stop in P_Take (3) stop in P_Take (dbx) run Running: zeus stopped in P_Take at line 2399 in file ".../exec.c" 2399 struct private_st *pst = &sr_private[MY_JS_ID]; (dbx) where P_Take(..), line 2399 in ".../exec.c" sr_invoke(locn, ibp), line 141 in "/ufs/usr.src.pd/srv2.2/rts/invoke.c" P_main(..), line 802 in ".../zeus.c" sr_build_context() at 0x2d9d4 attempt to read stack failed - bad frame pointer (dbx) Now line 802 of zeus.c is code for invoking operation DoneMsgr, not Take. The defining resource's spec looks like this: resource exec import value import address import stack type ProgArgs = rec (mach : cap exec ; env : ptr VALUE) optype Messenger () optype Code (env : ptr VALUE) op Exec (v : ptr VALUE) op DoneMsgr (msgr : cap Messenger) op Take (env : ptr VALUE ; next_stmt : ptr EXPR) .... The roles of these ops don't matter, but note that DoneMsgr is second and Take is third. If I swap the decls of Exec and DoneMsgr, then Exec is the one which has its invocation usurped by Take. If I insert a dummy operation, with something innocuous like some diagnostic write in the body, the compiler dies, viz: sr -b exec.sr "exec.c", line 1195: c50 undefined "exec.c", line 1420: c50 undefined "exec.c", line 1985: c50 undefined "exec.c", line 4060: c50 undefined "exec.c", line 4237: c50 undefined "exec.c", line 5885: c50 undefined "exec.c", line 6375: c50 undefined COMPILER MALFUNCTION (main.c/338): compiler generated bad code: exec.c I'm going to keep trying to get some skeletal code that produces the same effects, and will send a proper bug report when I can. Until then, any clues? Andy From gmt Thu Sep 2 10:48:28 1993 Received: from owl.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA27169; Thu, 2 Sep 1993 10:48:30 MST Date: Thu, 2 Sep 1993 10:48:28 MST From: "Gregg Townsend" Message-Id: <199309021748.AA06534@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Thu, 2 Sep 1993 10:48:28 MST To: andrew@cs.chalmers.se Subject: Re: Bug report (vague) for v2.2 Cc: info-sr That sounds like the sort of thing that can happen when the object files for different resources and globals get out of sync with each other. You might try deleting everything in the Interfaces directory and rebuilding from the beginning. 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 Mok-Kong.Shen@lrz.lrz-muenchen.d400.de Sun Sep 5 06:52:13 1993 Received: from cd1.lrz-muenchen.de by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA29824; Sun, 5 Sep 1993 06:52:13 MST Received: by cd1.lrz-muenchen.de; Sun, 5 Sep 93 15:52:08 +0200 X400-Trace: de*d400*lrz-muenchen; arrival 05 Sep 93 13:48:42 Z action Relayed X400-Internal-Trace: MTALRZCD1; arrival 05 Sep 93 15:52:02 +0200 action Relayed X400-Internal-Trace: MTALRZVEE; arrival 05 Sep 93 13:48:43 Z action Relayed P1-Message-Id: de*d400*lrz-muenchen; 930905154207141-MTALRZVEE Ua-Content-Id: 930905154207141- Original-Encoded-Information-Types: IA5-Text Message-Id: <930905154207141-MTALRZVEE*Mok-Kong.Shen@lrz.lrz-muenchen.d400.de> Date: 05 Sep 93 13:48:42 Z From: Mok-Kong.Shen@lrz-muenchen.de To: info-sr@cs.arizona.edu Subject: Any successful port to IBM RISC? Hi! I like very much to know if anybody has ported SR2.2 to IBM RISC and, if yes, how, since I don't have sufficient knowledge to be able to do that work. Straightforward running of make leads to the following: ------------------------------------------------------------ ...checking context switch code ./cstest >cstest.out running context switch test, arch = IBM RS6000 cmp cstest.out cstest.stdout cstest.out cstest.stdout differ: byte 140, line 6 make: 1254-004 The error code from the last command is 1. ------------------------------------------------------------ In the subdirectory csw the first 6 lines of cstest.out and cstest.stdout are as follows: --------------------------------------- creating stack for foo creating stack for bar creating stack for baz creating stack for boo creating stack for stir 1. boo1(one,two,three,) --------------------------------------- creating stack for foo creating stack for bar creating stack for baz creating stack for boo creating stack for stir 1. boo1(one,two,three,four) --------------------------------------- Could this be a strong indication that some system software packages of IBM RISC are in error, as installation of SR2.2 on e.g. SUN SPARC is without any problems? Best regards, M. K. Shen shen@lrz-muenchen.de From thofra@cs.tu-berlin.de Mon Sep 6 11:13:45 1993 Received: from mail.cs.tu-berlin.de by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA15972; Mon, 6 Sep 1993 02:16:40 MST Received: from poseidon.cs.tu-berlin.de by mail.cs.tu-berlin.de with SMTP id AA29556 (5.65c8/IDA-1.4.4(mail.m4[1.12]) for ); Mon, 6 Sep 1993 11:13:46 +0200 From: Thomas Frauenstein Message-Id: <199309060913.AA29556@mail.cs.tu-berlin.de> Subject: exit mail list To: info-sr@cs.arizona.edu Date: Mon, 6 Sep 1993 11:13:45 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 81 Hello ! Please take me out of the mailing list 'info-sr'. Thank's and Good bye From flibedin@math.tau.ac.il Mon Sep 6 14:21:41 1993 Received: from math.tau.ac.il ([132.66.40.1]) by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA22170; Mon, 6 Sep 1993 04:18:16 MST Received: from gemini.math.tau.ac.il by math.tau.ac.il (5.67/math.tau-921104) id AA13218; Mon, 6 Sep 93 14:19:32 +0300 Received: by gemini.math.tau.ac.il (5.67/math.sub-st921020) id AA04952; Mon, 6 Sep 93 14:21:41 +0300 Date: Mon, 6 Sep 93 14:21:41 +0300 From: flibedin@math.tau.ac.il Message-Id: <9309061121.AA04952@gemini.math.tau.ac.il> To: info-sr@cs.arizona.edu Please take me out of the SR mailing list. thanks, Fernando Libedinsky CS Dept, Tel-Aviv University flibedin@math.tau.ac.il From gmt Mon Sep 6 13:00:24 1993 Received: from owl.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA13193; Mon, 6 Sep 1993 13:00:25 MST Date: Mon, 6 Sep 1993 13:00:24 MST From: "Gregg Townsend" Message-Id: <199309062000.AA10886@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Mon, 6 Sep 1993 13:00:24 MST To: info-sr Subject: mailing list activity Just a reminder -- to withdraw from the mailing list, or change your address, or anything else of this sort, please send a message to info-sr-request@cs.arizona.edu If instead you send it to info-sr@... a copy is sent to everybody on the mailing list. 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 gmt Tue Sep 7 13:25:50 1993 Received: from owl.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA19602; Tue, 7 Sep 1993 13:25:51 MST Date: Tue, 7 Sep 1993 13:25:50 MST From: "Gregg Townsend" Message-Id: <199309072025.AA12445@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Tue, 7 Sep 1993 13:25:50 MST To: info-sr Subject: Re: Any successful port to IBM RISC? Date: 05 Sep 93 13:48:42 Z From: Mok-Kong.Shen@lrz-muenchen.de I like very much to know if anybody has ported SR2.2 to IBM RISC and, if yes, how, since I don't have sufficient knowledge to be able to do that work.... Could [cstest failures] be a strong indication that some system software packages of IBM RISC are in error, as installation of SR2.2 on e.g. SUN SPARC is without any problems? I think it's more likely to indicate a problem in the RS6000 code. The RS6000 code is unchanged from SR 2.1, but the context switch test is a little more stringent to better test the SR system's requirements. It appears that this has uncovered a problem: the fourth argument passed to sr_build_context is not being passed along when the stack is activated. I can't work on this myself, because I have no RS6000 here, but perhaps somebody else can follow up this clue. 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 gmt Mon Sep 13 08:13:05 1993 Received: from owl.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA11897; Mon, 13 Sep 1993 08:13:10 MST Date: Mon, 13 Sep 1993 08:13:05 MST From: "Gregg Townsend" Message-Id: <199309131513.AA18981@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Mon, 13 Sep 1993 08:13:05 MST To: info-sr Subject: Fix for SR running on IBM RS6000 Cc: J.Crowcroft@cs.ucl.ac.uk, Mok-Kong.Shen@lrz-muenchen.de, caillat@mesioe.obspm.circe.fr, kohlwayc@gaia.ecs.csus.edu In Version 2.2 of SR, the context switch code for the IBM RS6000 series (csw/rs6000.s) fails the context switch test due to an unterminated comment. To fix this, edit line 151, which reads sr_startup_context: /* only need args first time proc starts and terminate the comment by adding `*/' at the end. We do not know if this will correct the RS6000 problem involving stack underflow. If you have had that problem in the past, we'd appreciate hearing (by mail to sr-project@cs.arizona.edu) whether this fixes it. We thank Jon Crowcroft for tracking down this problem. 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@riogrande.cs.tcu.edu Fri Oct 15 01:39:11 1993 Received: from ALPHA.IS.TCU.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA19769; Thu, 14 Oct 1993 23:39:37 MST Received: from riogrande.cs.tcu.edu (TCUCS6.CS.TCU.EDU) by ALPHA.IS.TCU.EDU (PMDF #2903 ) id <01H44H4RU4JK00216N@ALPHA.IS.TCU.EDU>; Fri, 15 Oct 1993 01:39:30 CDT Received: by riogrande.cs.tcu.edu (4.1/SMI-4.1) id AA05381; Fri, 15 Oct 93 01:39:11 CDT Date: 15 Oct 1993 01:39:11 -0500 (CDT) From: morgenst@riogrande.cs.tcu.edu Subject: co question To: info-sr@cs.arizona.edu Message-Id: <9310150639.AA05381@riogrande.cs.tcu.edu> Content-Transfer-Encoding: 7BIT Hello, Could someone enlighten me as to why the following two pieces of code behave differently. Is the co stmt not able to concurrently invoke procs that are on distinct vm's? In the second program (t2.sr), the co stmt behaves exactly like an fa stmt -- the code is a stripped down version derived from a much larger program that attempts to concurrently invoke a worker proc's on vm's that are created on different physical machines. Thanks for your help! Craig Morgenstern morgenst@riogrande.cs.tcu.edu =========================================================================== # file : t1.sr resource Main() op worker(i : int) proc worker(i) printf("Worker %d here\n", i) flush(stdout) if i = 1 -> nap(60000) fi printf("Worker %d exiting\n", i) end co (i := 1 to 2) worker(i) oc end Main % sr -o t1.x t1.sr % t1.x Worker 1 here Worker 2 here Worker 2 exiting <---------- 60000 millisecond delay (what we would expect) Worker 1 exiting =========================================================================== # file : t2.sr resource Worker op worker(i:int) body Worker() proc worker(i) printf("Worker %d here\n", i) flush(stdout) if i = 1 -> nap(60000) fi printf("Worker %d exiting\n", i) end end Worker resource Main import Worker body Main() var vm_cap[1:2] : cap vm var worker_cap[1:2] : cap Worker fa i := 1 to 2 -> vm_cap[i] := create vm() af fa i := 1 to 2 -> worker_cap[i] := create Worker() on vm_cap[i] af co (i := 1 to 2) worker_cap[i].worker(i) oc end Main % sr -o t2.x t2.sr % t2.x Worker 1 here <---------- 60000 millisecond delay (why doesn't Worker 2 start?) Worker 1 exiting Worker 2 here Worker 2 exiting From morgenst@riogrande.cs.tcu.edu Fri Oct 15 13:07:59 1993 Received: from ALPHA.IS.TCU.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA24922; Fri, 15 Oct 1993 11:08:25 MST Received: from riogrande.cs.tcu.edu (TCUCS6.CS.TCU.EDU) by ALPHA.IS.TCU.EDU (PMDF #2903 ) id <01H4556RTMA8001YXF@ALPHA.IS.TCU.EDU>; Fri, 15 Oct 1993 13:08:19 CDT Received: by riogrande.cs.tcu.edu (4.1/SMI-4.1) id AA15058; Fri, 15 Oct 93 13:07:59 CDT Date: 15 Oct 1993 13:07:59 -0500 (CDT) From: morgenst@riogrande.cs.tcu.edu Subject: co question update To: info-sr@cs.arizona.edu Message-Id: <9310151807.AA15058@riogrande.cs.tcu.edu> Content-Transfer-Encoding: 7BIT An update to my previous question about the behavior of co invoking procs on different vm's: The following kludge seems to fix the problem. BTW, we're running SUNOS 4.1.1 on a Sparc-2. This behavior seems to be a bug. Thanks again, craig ============================================================================ # file :t4.sr resource Worker op worker(i:int) body Worker() proc worker(i) printf("Worker %d here\n", i) flush(stdout) if i = 1 -> nap(60000) fi printf("Worker %d exiting\n", i) end end Worker resource Main import Worker body Main() var vm_cap[1:2] : cap vm var worker_cap[1:2] : cap Worker procedure dummy(i : int) worker_cap[i].worker(i) end fa i := 1 to 2 -> vm_cap[i] := create vm() af fa i := 1 to 2 -> worker_cap[i] := create Worker() on vm_cap[i] af co (i := 1 to 2) dummy(i) oc end Main % t4.x Worker 1 here Worker 2 here Worker 2 exiting <-------------- delay here (what we would expect) Worker 1 exiting From ttdsuen@undergrad.math.uwaterloo.ca Fri Oct 15 17:05:48 1993 Received: from undergrad.math.uwaterloo.ca by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA05748; Fri, 15 Oct 1993 14:06:03 MST Received: from napier.uwaterloo.ca by undergrad.math.uwaterloo.ca id <43220-2>; Fri, 15 Oct 1993 17:05:55 -0400 From: Daniel Suen To: info-sr@cs.arizona.edu, morgenst@riogrande.cs.tcu.edu Subject: Re: co question update Message-Id: <93Oct15.170555edt.43220-2@undergrad.math.uwaterloo.ca> Date: Fri, 15 Oct 1993 17:05:48 -0400 Hello, I have received your e-mail and I do not know why as we do not have any connection with each other. I think you must be sending the e-mail to a wrong address location. Daniel From gmt Fri Oct 15 18:46:00 1993 Received: from owl.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA21088; Fri, 15 Oct 1993 18:46:14 MST Received: by owl.cs.arizona.edu (5.0/SMI-SVR4) id AA17772; Fri, 15 Oct 93 18:46:00 MST Date: Fri, 15 Oct 93 18:46:00 MST From: gmt (Gregg Townsend) Message-Id: <9310160146.AA17772@owl.cs.arizona.edu> To: morgenst@riogrande.cs.tcu.edu Cc: info-sr Subject: Re: co question Content-Length: 2347 Thanks for the report. It's a bug, all right. It can be fixed by applying the patch below in the "rts" source directory. 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 ------------------------------------------------------------------------------- diff -c old/invoke.c ./invoke.c *** old/invoke.c Fri Oct 15 16:58:10 1993 --- ./invoke.c Fri Oct 15 17:32:08 1993 *************** *** 93,102 **** ph = (Pach) ibp; ibp = (Invb) sr_remote (ibp->opc.vm, REQ_INVOKE, ph, ph->size); sr_free ((Ptr) ph); - - if (ibp != NULL && ibp->type == REM_COCALL_IN) - sr_co_call_done (ibp); - return (Ptr) ibp; } --- 93,98 ---- diff -c old/net.c ./net.c *** old/net.c Fri Oct 15 17:34:07 1993 --- ./net.c Fri Oct 15 17:44:10 1993 *************** *** 312,321 **** case ACK_DESTROY: case ACK_DESTVM: case ACK_CALLME: - case ACK_INVOKE: case ACK_RECEIVE: ph->rem->reply = ph; V (ph->rem->wait); ph = 0; break; --- 312,330 ---- case ACK_DESTROY: case ACK_DESTVM: case ACK_CALLME: case ACK_RECEIVE: ph->rem->reply = ph; V (ph->rem->wait); + ph = 0; + break; + + case ACK_INVOKE: + if (((Invb) ph)->type == REM_COCALL_IN) + sr_co_call_done ((Invb) ph); + else { + ph->rem->reply = ph; + V (ph->rem->wait); + } ph = 0; break; diff -c old/remote.c ./remote.c *** old/remote.c Fri Oct 15 17:03:09 1993 --- ./remote.c Fri Oct 15 17:25:08 1993 *************** *** 33,38 **** --- 33,39 ---- int size; { struct remd_st rem; + Invb ibp; if (! (sr_net_known ((int) dest))) contact ((int) dest); /* establish contact if none yet made */ *************** *** 39,47 **** ph->priority = CUR_PROC->priority; ! if (type == REQ_INVOKE && ((Invb) ph)->replied) { ! /* sends and forwards are not ack'd */ sr_net_send (dest, type, ph, size); return NULL; --- 40,49 ---- ph->priority = CUR_PROC->priority; ! ibp = (Invb) ph; ! if (type == REQ_INVOKE && (ibp->replied || ibp->type == REM_COCALL_IN)) { ! /* sends and forwards are not ack'd, and we don't wait on a cocall */ sr_net_send (dest, type, ph, size); return NULL; From morgenst@riogrande.cs.tcu.edu Sun Nov 7 22:13:28 1993 Received: from ALPHA.IS.TCU.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA11386; Sun, 7 Nov 1993 21:13:42 MST Received: from riogrande.cs.tcu.edu (TCUCS6.CS.TCU.EDU) by ALPHA.IS.TCU.EDU (PMDF #2903 ) id <01H51SXRV5O0001742@ALPHA.IS.TCU.EDU>; Sun, 7 Nov 1993 22:13:36 CST Received: by riogrande.cs.tcu.edu (4.1/SMI-4.1) id AA13683; Sun, 7 Nov 93 22:13:28 CST Date: 07 Nov 1993 22:13:28 -0600 (CST) From: morgenst@riogrande.cs.tcu.edu Subject: Scheduling expressions in shared operations To: info-sr@cs.arizona.edu Message-Id: <9311080413.AA13683@riogrande.cs.tcu.edu> Content-Transfer-Encoding: 7BIT Hello, Is it supposed to be possible to have several processes on different virtual machines all containing an input statement with a scheduling expression for the same message queue? I can't find any statement in Andrew and Olsson's text to the contrary, but a program that tries this results in immediate deadlock. Something along the lines of what follows (the main resource creates the Server, puts the initial item in the bag, and then creates the Workers). If the scheduling expression is deleted, then everything works fine. Just wondering; it's easy enough to do the same thing more efficiently in other ways that do work. thanks, craig morgenst@riogrande.cs.tcu.edu ======================================================================== resource Server op bag(k : key; i : item) {send} body Server() end Server resource Worker import Server body Worker(scap : cap Server) process worker do true -> in scap.bag(k,i) by k -> # For a small average bag size and lots of # work to do per item, this might be feasible... do work on i send scap.bag(new_keys, new_items) ni end end Worker From gmt Fri Nov 12 17:26:30 1993 Received: from owl.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA25851; Fri, 12 Nov 1993 17:26:54 MST Received: by owl.cs.arizona.edu (5.0/SMI-SVR4) id AA05291; Fri, 12 Nov 93 17:26:30 MST Date: Fri, 12 Nov 93 17:26:30 MST From: gmt (Gregg Townsend) Message-Id: <9311130026.AA05291@owl.cs.arizona.edu> To: morgenst@riogrande.cs.tcu.edu Cc: info-sr Subject: Re: Scheduling expressions in shared operations Content-Length: 990 From: morgenst@riogrande.cs.tcu.edu Is it supposed to be possible to have several processes on different virtual machines all containing an input statement with a scheduling expression for the same message queue? No. Prior to SR 2.2, they couldn't share the queue at all, and that is what is documented in the first printing of the Andrews/Olsson text. The rule now is: An operation capability can replace an operation name in an input statement, without regard to how the capability was created, subject to meeting *either* of the following two restrictions: * the input statement has just one arm and no by or st (but it may have an else), or * the capability references an operation in the current resource (When you reference "scap.bag" you are really referencing its capability.) 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 andrew@cs.chalmers.se Sat Nov 13 16:56:53 1993 Received: from animal.cs.chalmers.se by optima.cs.arizona.edu (5.65c/15) via SMTP id AA07542; Sat, 13 Nov 1993 08:58:02 MST Message-Id: <9311131556.AA25658@animal.cs.chalmers.se> Received: from localhost.cs.chalmers.se by animal.cs.chalmers.se (5.60+IDA/3.14+gl) id AA25658; Sat, 13 Nov 93 16:56:54 +0100 To: info-sr@cs.arizona.edu Subject: SR on DEC Alphas? Date: Sat, 13 Nov 1993 16:56:53 +0100 From: Andrew Moran I'm interested in finding out if anyone is working on porting SR to DEC Alphas. Andy From gmt Sat Nov 13 17:28:58 1993 Received: from owl.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA29713; Sat, 13 Nov 1993 17:29:25 MST Received: by owl.cs.arizona.edu (5.0/SMI-SVR4) id AA06309; Sat, 13 Nov 93 17:28:58 MST Date: Sat, 13 Nov 93 17:28:58 MST From: gmt (Gregg Townsend) Message-Id: <9311140028.AA06309@owl.cs.arizona.edu> To: andrew@cs.chalmers.se Cc: info-sr Subject: Re: SR on DEC Alphas? Content-Length: 306 We have a working Dec Alpha port that we can make available by FTP to people who need it. Send mail to sr-project@cs.arizona.edu if interested. 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 cngauv@st.nepean.uws.edu.au Wed Nov 17 18:22:06 1993 Received: from lancelot.st.nepean.uws.EDU.AU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA17569; Wed, 17 Nov 1993 00:35:18 MST Received: from tor.st.nepean.uws.edu.au (tor) by lancelot.st.nepean.uws.edu.au with SMTP id AA24987 (5.65c/IDA-1.4.4 for ); Wed, 17 Nov 1993 18:37:14 +1100 Received: by tor.st.nepean.uws.edu.au id AA00834 (5.65c/IDA-1.4.4 for info-sr@cs.arizona.edu); Wed, 17 Nov 1993 18:35:20 +1100 Date: Wed, 17 Nov 1993 18:22:06 +1100 (EST) From: Cheng Ngauv Subject: manipulating arrow keys via SR-Win To: info-sr@cs.arizona.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII hello Concurrent Programmers of the world, I have been using SR for over 6 months and have come across a problem in doing my major project. I am programming a screen editor using SR-Win and have no idea of how to manipulate the arrow keys on my screen. The ascii codes for function and arrow keys do not register when my srwin program executes. If any one can help, please do. My email address is cngauv@st.nepean.uws.edu.au Please reply a.s.a.p. Thank you. Cheng Ngauv University of Western Sydney - Nepean. Australia. From azhao@cc.gatech.edu Wed Nov 17 03:59:25 1993 Received: from burdell.cc.gatech.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA19687; Wed, 17 Nov 1993 01:59:28 MST Received: from oakmont.cc.gatech.edu (oakmont.cc.gatech.edu [130.207.119.218]) by burdell.cc.gatech.edu (8.6.4/8.6.4) with ESMTP id DAA06528; Wed, 17 Nov 1993 03:59:26 -0500 Received: from localhost (azhao@localhost) by oakmont.cc.gatech.edu (8.6.4/8.6.4) id DAA12773; Wed, 17 Nov 1993 03:59:25 -0500 From: "Q. Alex Zhao" Message-Id: <199311170859.DAA12773@oakmont.cc.gatech.edu> Subject: Re: manipulating arrow keys via SR-Win To: cngauv@st.nepean.uws.edu.au (Cheng Ngauv) Date: Wed, 17 Nov 93 3:59:25 EST Cc: info-sr@cs.arizona.edu In-Reply-To: ; from "Cheng Ngauv" at Nov 17, 93 6:22 pm X-Mailer: ELM [version 2.3 PL11] According to Cheng Ngauv in a previous message: ] ] I have been using SR for over 6 months and have come across a ] problem in doing my major project. I am programming a screen ] editor using SR-Win and have no idea of how to manipulate the ] arrow keys on my screen. The ascii codes for function and arrow ] keys do not register when my srwin program executes. ] If any one can help, please do. ] This is a problem with SRWin. As it is now, SRWin can't detect arrow keys -- because arrow keys usually generate multiple characters but the SRWin event structure has space only for one character... We may change the library some, and if we can provide access to arrow keys, we will let you know. I suggested to another person having the same problem as yours to use single character keys instead. But I think that probably cannot apply to your project. For a editor either control keys or a mouse (point-and-click) would be ok I guess. Cheers, = Q. Alex Zhao ~{0"UT~} ! Graphics, Visualization & Usability Center Email: azhao@cc.gatech.edu ! College of Computing FAX: 404-853-9378 ! Georgia Institute of Technology Lab: 404-894-9633 ! Atlanta, Georgia 30332-0280 From thomas@is.s.u-tokyo.ac.jp Wed Dec 15 10:21:54 1993 Received: from camille.is.s.u-tokyo.ac.jp by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA24590; Tue, 14 Dec 1993 18:23:56 MST Received: from myriem.is.s.u-tokyo.ac.jp by camille.is.s.u-tokyo.ac.jp (5.65/TISN-1.3/R2) id AA25877; Wed, 15 Dec 93 10:22:10 +0900 Received: by myriem.is.s.u-tokyo.ac.jp (5.65/TISN-1.0N/1.8) id AA00135; Wed, 15 Dec 93 10:21:54 +0900 Date: Wed, 15 Dec 93 10:21:54 +0900 From: thomas@is.s.u-tokyo.ac.jp Message-Id: <9312150121.AA00135@myriem.is.s.u-tokyo.ac.jp> To: info-sr@cs.arizona.edu Subject: array of op Hi, I'm trying to use the "array of op" syntax possibility : For instance : resource arrop op x[3]() body arrop () op term() process dummy do true -> in x[1]() -> write('+') [] x[2]() -> write('-') [] x[3]() -> write('*') [] term () -> exit ni od end fa i := 1 to 100 -> x[i%3+1]() af term() end arrop works fine. But i wish every x[i]() to be a proc. resource arrop op x[3]() body arrop () op term() proc x[1]() ... end proc x[2]() ... end ... The compiler rejects this because x[1] is not a valid proc name. Is there any other way to achieve the same goal ? Is there any theoretical reason why to prohibit this syntax? Thanx. --laurent Dr. Laurent Thomas email: thomas@is.s.u-tokyo.ac.jp Department of Information Science. Faculty of Science. University of Tokyo. Bunkyo-Ku, Tokyo 113, Japan From gmt Wed Dec 15 17:33:50 1993 Received: from owl.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA05638; Wed, 15 Dec 1993 17:33:52 MST Received: by owl.cs.arizona.edu (5.0/SMI-SVR4) id AA03181; Wed, 15 Dec 1993 17:33:50 +0700 Date: Wed, 15 Dec 1993 17:33:50 +0700 From: gmt (Gregg Townsend) Message-Id: <9312160033.AA03181@owl.cs.arizona.edu> To: info-sr Subject: Re: array of op Content-Length: 769 From: thomas@is.s.u-tokyo.ac.jp I'm trying to use the "array of op" syntax possibility : ... The compiler rejects this because x[1] is not a valid proc name. Is there any other way to achieve the same goal ? Is there any theoretical reason why to prohibit this syntax? You can approximate what you want by declaring an array of capabilities and initializing them to point to different procs. You can export such an array from a global, but not from a resource. I don't see any obvious reason why it couldn't be implemented, but it would take a bit of effort. 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 gmt Tue Dec 21 17:25:46 1993 Received: from owl.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA04552; Tue, 21 Dec 1993 17:25:49 MST Received: by owl.cs.arizona.edu (5.0/SMI-SVR4) id AA05381; Tue, 21 Dec 1993 17:25:46 +0700 Date: Tue, 21 Dec 1993 17:25:46 +0700 From: gmt (Gregg Townsend) Message-Id: <9312220025.AA05381@owl.cs.arizona.edu> To: info-sr Subject: SR for Linux and Dec Alpha Content-Length: 828 I've placed a new version of SR, version 2.2.1, in the "sr" directory of the anonymous FTP area on cs.arizona.edu. This is primarily a maintenance release. It adds support for the Dec Alpha architecture and for 386/486 machines running the Linux operating system. There is also a fix for the bug that caused remote co-calls to be serialized, and a minor enhancement to SRWin to pass keysm values with keypress events. As usual, please send any questions to sr-project@cs.arizona.edu. Because the University of Arizona is shutting down from December 24th to January 2nd, there may be a delay before we respond. The FTP server will remain up during this interval. 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 admin@ibmserv.edu.tw Tue Dec 21 17:05:25 1993 Received: from ibmserv.edu.tw by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA25585; Wed, 22 Dec 1993 01:31:04 MST Received: by ibmserv.edu.tw (AIX 3.2/UCB 5.64/4.03) id AA12082; Tue, 21 Dec 1993 17:05:25 -1600 Date: Tue, 21 Dec 1993 17:05:25 -1600 From: admin@ibmserv.edu.tw Message-Id: <9312220905.AA12082@ibmserv.edu.tw> To: gmt@cs.arizona.edu, info-sr@cs.arizona.edu Subject: Re: SR for Linux and Dec Alpha Hi, Will the SR support the data type of COMPLEX, DOUBLE COMPLEX and EXTENDED FLOAT for the so-called Numeric Intensive Computing? one of the major users in the parallel computing is belongs to this catagory, if SR is equipped with those date types, then it will attract more SR users, I think. Futher, based on Vincent Freeh's report, the performance on SR is relative weak compare to C or SISAL due to array addressing, correct me if I am wrong. Is there any enhancement activity to do with that in the future? Cinloon *******I am sure that SR is terrific******* From gmt Wed Dec 22 10:19:03 1993 Received: from owl.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA20312; Wed, 22 Dec 1993 10:19:05 MST Received: by owl.cs.arizona.edu (5.0/SMI-SVR4) id AA06383; Wed, 22 Dec 1993 10:19:03 +0700 Date: Wed, 22 Dec 1993 10:19:03 +0700 From: gmt (Gregg Townsend) Message-Id: <9312221719.AA06383@owl.cs.arizona.edu> To: info-sr Subject: numeric datatypes in SR Content-Length: 712 SR's only floating-point type is its type "real", which is implemented by the C type "double". SR provides no built-in complex type. SR's array accesses, especially for multidimensional arrays, are a bit slower than C (and presumably Fortran). Some of this can be attributed to the greater flexibility of SR arrays (e.g. adjustable bounds), some from translating SR into C instead of machine code, and some because we haven't spent a large amount of time tuning the implementation. We don't have any major improvement efforts planned at this time. 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 beavers@engr.LaTech.edu Mon Dec 27 16:26:30 1993 Received: from aurora.engr.LaTech.edu by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA23489; Mon, 27 Dec 1993 15:26:32 MST Received: from localhost (beavers@localhost) by aurora.engr.latech.edu (8.6.4/8.6.4) id QAA04843 for info-sr@cs.arizona.edu; Mon, 27 Dec 1993 16:26:30 -0600 From: "Phillip M. Beavers" Message-Id: <199312272226.QAA04843@aurora.engr.latech.edu> Subject: Eight Queens Problem To: info-sr@cs.arizona.edu Date: Mon, 27 Dec 1993 16:26:30 -0600 (CST) X-Mailer: ELM [version 2.4 PL22.4] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1624 Perhaps this message is not directly intended for this mailing list, but I thought it best to check and see if any of the recipients of this list could help with the problem I am attempting to solve. I am new to SR and to parallel and concurrent programming in general, so I am having problems with a program I have been asked to write. The program is supposed to solve the "classic" problem of Eight Queens where eight queens are placed on a standard chessboard in such a way that none can attack another. This program is to be written in SR. Could anyone tell me of a book or an article that might have been published somewhere in which a general algorithm that might work on this problem might be? I am at a lost and am trying to find any published information I can about this algorithm. Even an iterative form of the algorithm would be a start. Any help you could give me would be greatly appreciated. |============================================================================| | Phillip M. Beavers beavers@engr.latech.edu | | 404 West Texas Street scpmb@vm.cc.latech.edu | | Ruston, LA 71270 | | (318) 254-1497 | | | | I do not claim to know everything, for to know everything, and live by it, | | would be perfection and perfection is an ideal, not a reality. | |============================================================================| From greg Tue Dec 28 09:05:50 1993 Received: from paloverde.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA06886; Tue, 28 Dec 1993 09:05:52 MST Date: Tue, 28 Dec 1993 09:05:50 MST From: "Greg Andrews" Message-Id: <199312281605.AA01711@paloverde.cs.arizona.edu> Received: by paloverde.cs.arizona.edu; Tue, 28 Dec 1993 09:05:50 MST To: beavers@engr.LaTech.edu, info-sr@cs.arizona.edu Subject: Re: Eight Queens Problem Many books for a second course in Computer Science discuss the 8-queens problem, typically in a chapter on recursion and/or backtracking. If your assignment is to develop a *parallel* solution, I can give you a stronger hint on where to find a sequential program in SR. -- Greg Andrews