From pazy@world.std.com Fri Dec 1 00:17:13 1995 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05089; Fri, 1 Dec 95 00:17:13 EST Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA23247; Fri, 1 Dec 95 00:17:19 EST Received: from europe.std.com by sw-eng.falls-church.va.us (8.7.1/) id FAA07845; Fri, 1 Dec 1995 05:17:11 GMT Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id AAA12964; Fri, 1 Dec 1995 00:17:10 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA10373; Fri, 1 Dec 1995 00:12:02 -0500 Date: Fri, 1 Dec 1995 00:12:02 -0500 From: pazy@world.std.com (Offer Pazy) Message-Id: <199512010512.AA10373@world.std.com> To: ada-comment@sw-eng.falls-church.va.us Subject: Re: Shared Variables !topic signaling concept may be incomplete !reference RM95-9.10(11) !keywords signaling, shared variables, sequential !reference 95-5398.a Erhard Ploedereder 95-11-29 !from Offer Pazy 95-11-30 <> !discussion Erhard, I agree with your analysis and I also agree that it would be *nice* if termination would be folded in the signalling concept. But: > Clearly, one would like this idiom to work as "expected" and shared > variables, whose changed values are cached by the implementation of local > tasks, to be updated upon termination at the latest. Why is it so important? I mean, why is it so "clear"? Since Ada does not provide a way to really wait on a termination of another task (if we exclude the business of masters which is another issue), only to query the 'terminated attribute, I don't see where spin-waiting will be the practical way to achieve that. With a simple PO, you can get the same result, admittedly with more overhead, but I think that in a real life example, using a PO will be much more realistic. So to summarize, I am interested to know why you find this example so useful? On the implementation side, there is (admittedly small) penalty for doing what you ask for. If the reason that Stop_Pulse is not safely available to T is becuase it is in a register, it is practically guaranteed that when Local_Task terminates. all the register-variables (those which are visible to other tasks), will be flushed back to memory. No problem here. But your example suggests that you were thinking of a multi-processor, presumably with enough processors so you don't care of dedicating one for the spin-wait. In these cases we have to think about non-consistent caches. Unless the implementatation keeps a "good" (i.e. quite elaborate) track of all the global variables that the task touches, the entire cache will have to be flushed to the real memory when the task terminates. (I may be wrong here, but I think that most such caches don't allow you to flush individual words. They usually flush the entire cache or regions of it.) Just a thought. Offer Pazy 31 Robinwood Ave. Boston, MA 02130 USA (617)522-5988 pazy@world.std.com From bobduff@world.std.com Fri Dec 1 11:01:16 1995 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA12728; Fri, 1 Dec 95 11:01:16 EST Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA02015; Fri, 1 Dec 95 11:01:23 EST Received: from europe.std.com by sw-eng.falls-church.va.us (8.7.1/) id QAA21966; Fri, 1 Dec 1995 16:01:14 GMT Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id LAA20918; Fri, 1 Dec 1995 11:00:58 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA06838; Fri, 1 Dec 1995 11:00:57 -0500 Date: Fri, 1 Dec 1995 11:00:57 -0500 From: bobduff@world.std.com (Robert A Duff) Message-Id: <199512011600.AA06838@world.std.com> To: kst@thomsoft.com Cc: ada-comment@sw-eng.falls-church.va.us In-Reply-To: <9511301014.AA10458@pulsar.telesoft> (kst@thomsoft.com) Subject: Re: External interactions !topic External interactions !reference RM95-1.1.3(15) !reference 95-5400.a Keith Thompson 95-11-30 !from Bob Duff <> > Is the normal termination of a main program with no function result or > parameters an external interaction? It isn't defined as one in paragraphs > 9..14 of RM95-1.1.3. > > In particular, the following main program has no external interactions > as defined in 1.1.3: > > procedure Main is > begin > loop > null; > end loop; > end Main; > > May an implementation optimize out the infinite loop? I suppose so. >... The resulting > program also has no external interactions; the only difference is that > it terminates. > > (This question was inspired by an article, , > posted to comp.std.c by Dan Pop.) - Bob