Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!yale!quasi-eli!cs.yale.edu!ghostwheel.eng.yale.edu!llw From: llw@ghostwheel.eng.yale.edu (Louis L. Whitcomb) Newsgroups: comp.sys.transputer Subject: Mea Culpa: Re: Anarchic protocol ANY (occam2) Message-ID: Date: 21 May 91 09:39:48 GMT References: <9105152020.AA15174@theory.TN.CORNELL.EDU> <7730@ecs.soton.ac.uk> Sender: news@cs.yale.edu (Usenet News) Organization: Yale University, Center for Systems Sciences Lines: 40 In-Reply-To: dbc@ecs.soton.ac.uk's message of 20 May 91 10: 08:15 GMT Nntp-Posting-Host: corwin.eng.yale.edu In article <7730@ecs.soton.ac.uk> dbc@ecs.soton.ac.uk (Bryan Carpenter) writes: In llw@ghostwheel.eng.yale.edu (Louis L. Whitcomb) writes: >... >The moral of the story: If you use OCCAM2, use explicit protocols - >even though they are cumbersome and restrictive. It is hard to track >down bugs without them. >Note that ihe implementation of channel communication in the newly >released INMOS ANSI C compiler does *not* suffer from this curious >design flaw. I haven't looked at inmos C very closely. How do they get round the "design flaw" (if that's what it is)? Bryan Greetings Folks: In a previous post, quoted above, I incorrectly asserted that the channel behavior in question (when sending and receiving processes disagree on number or size of communication events) differed between the OCCAM compiler and the new C compiler. My more learned colleagues remind me that the same behavior may be demonstrated in either environment. Postings by various authors have covered this topic pretty well. The Best, -Louis. -- Louis L. Whitcomb llw@corwin.eng.yale.edu ph: (203) 432-4237 Yale Robotics Laboratory fx: (203) 432-7481 Department of Electrical Engineering, 1968 Yale Station, New Haven, CT 06520