CVS difference for ai05s/ai05-0167-1.txt

Differences between 1.6 and version 1.7
Log of other versions for file ai05s/ai05-0167-1.txt

--- ai05s/ai05-0167-1.txt	2011/01/25 05:47:49	1.6
+++ ai05s/ai05-0167-1.txt	2011/02/10 06:23:22	1.7
@@ -1,4 +1,4 @@
-!standard  D.16.1                               11-01-23    AI05-0167-1/05
+!standard  D.16.1                               11-02-09    AI05-0167-1/06
 !standard  C.3.2
 !class Amendment 09-10-22
 !status work item 09-10-22
@@ -63,14 +63,13 @@
 the processors and on which the environment task executes. If no
 tasks are explicitly assigned to other domains, then all tasks will
 execute on this default domain. A task executing in the default
-domain can be assigned to another dispatching domain. A task will
-always activate in the dispatching domain of its activating task (as
-the activating task will be blocked).
+domain can be assigned to another dispatching domain. By default,
+a task will execute in the dispatching domain of its activating task.
 
-For protected objects there is no need for affinities, it is the
+For protected objects there is no need for affinities; it is the
 tasks that have domains and possibly an assigned CPU. PO code
 will run on the task's CPU. There is however a need to know
-on what CPU interrupt code will execute, this will allow an
+on what CPU interrupt code will execute; this will allow an
 associated task to be assigned the same CPU.
 
 !wording
@@ -149,32 +148,10 @@
 
 Dynamic Semantics
 
-A pragma Dispatching_Domain assigns the task to the specified domain. During
-activation, a task executes in the domain of the activating task; afterward, it
-executes in the domain to which it is assigned. If the task is not assigned to
-any domain, it executes in that of the activating task.
-
-[Author's question:
-
-The above matches my understanding of the minutes, but I'm still having trouble
-with it. Activation is over when a task reaches its "begin" -- do we really want
-to insist that it move to a different domain, and therefore a different CPU, at
-that time? Suppose we say:
-
-    Assign_Task(DD_3, CPU_7, My_Task);
-
-And suppose My_Task is then activated by the environment task, which is running
-in System_Dispatching_Domain, on CPU_2. So during activation, My_Task runs in
-System_Dispatching_Domain, but it certainly can't run on CPU_7, because that's
-part of DD_3.  But that contradicts the semantics of Assign_Task below.
-
-To me it seems much simpler if a task is assigned to a domain once and for all
-(doesn't switch domains at the "begin"), and always runs on its assigned CPU
-(before and after "begin"), and that CPU is always part of that domain.  (Except
-the Not_A_Specific_CPU case, of course).  We can change CPU affinity, but not
-the domain, of a task, right?
-
-End Author's Question]
+A pragma Dispatching_Domain assigns the task to the specified domain.
+If a task is not explictly assigned to any domain,
+it is assigned to that of the activating task.
+A task always executes on some CPU in its domain.
 
 If a task contains a CPU pragma and a Dispatching_Domain pragma, and the CPU
 value is not contained within the range of processors for the Dispatching_Domain
@@ -189,12 +166,7 @@
 if a processor has a task assigned to it, or if the allocation would leave
 System_Dispatching_Domain empty. A call of Create will raise
 Dispatching_Domain_Error if the calling task is not the environment task, or
-after the call to the main subprogram.
-
-[Author's Question: Is that last sentence what we want?  The minutes say
-"Program_Error", but everything else here raises Dispatching_Domain_Error, so I
-used that. But more importantly: It's OK to create domains after tasks start
-running? And it's bad to create domains in the main procedure?]
+if Create is called after the call to the main subprogram.
 
 The function Get_First_CPU returns the first CPU in Domain; Get_Last_CPU
 returns the last one.
@@ -496,7 +468,7 @@
 
 
 In addition to these two packages there is a further new pragma
-required to control the affinity of tasks during activation:
+required to control the affinity of tasks:
 
 pragma Dispatching_Domain (DD : Dispatching_Domain);
 
@@ -596,7 +568,305 @@
 importantly: It's OK to create domains after tasks start running?  And it's bad
 to create domains in the main procedure?
 
+****************************************************************
+
+From: Alan Burns
+Sent: Monday, January 31, 2011  5:38 AM
+
+I note in the minutes of the telephone meeting that AI 167 still has a couple of
+issues open. As I will not be at the next full meeting I thought it would be
+useful to try and get closure on these by email - but note Bob is now
+responsible for this AI (not me).
+
+The main issue concerns a task (T) that is destine to run in one Dispatching
+Domain (D1) but whose activating task (A) is running in another domain (D2).
+
+Two possibilities -
+
+1) T is activated in D2 and then moves to D1 at 'begin'
+2) T is activated and executed on D2
+
+Currently the AI favours 1) on the basis that A is blocked waiting for T to
+finish activating - this is a dependency between dispatching domains which
+should be avoided as much as possible.
+
+However, as Bob notes in the current version of the AI, it is strange to have T
+start in one dispatching domain (on some CPU) and then move to another domain
+(and hence a different CPU) at the point that it moves from activating to
+executing.
+
+I agree with Bob. Although it is useful to eliminate A's dependency on another
+Dispatching Domain, it is not the only situation in which it occurs (others are
+rendezvous across domains, waiting for termination). It will be much more
+efficient to allow T to activate and execute on the same CPU. Also the
+programmer can program the other situation if needed (by not using the domain
+pragma, and then calling Assign_Task as the first executable statement).
+
+So my view is that we change.
+
+The other question concerned the name of the exception to be raised if Create is
+called 'late' - I have no view on this! - but I'm sure others have!! Perhaps the
+current wording 'or after the call' is not quite clear?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, January 31, 2011  7:10 AM
+
+> I note in the minutes of the telephone meeting that AI 167 still has a
+> couple of issues open. As I will not be at the next full meeting I
+> thought it would be useful to try and get closure on these by email -
+> but note Bob is now responsible for this AI (not me).
+
+Thanks for answering my questions, Alan.  I'll update the AI.
+If anybody else wants to weigh in, please speak up.
+
+> Two possibilities -
+>
+> 1) T is activated in D2 and then moves to D1 at 'begin'
+> 2) T is activated and executed on D2
+
+Right, but note that we should stick with RM terminology to avoid confusion:
+activation is part of execution.
+
+(I've never understood why activation is special -- that is, why the activator
+should wait for notification from the activatee(s).  Strange.)
+
+****************************************************************
+
+From: Alan Burns
+Sent: Monday, January 31, 2011  7:22 AM
+
+...
+>> Two possibilities -
+>>
+>> 1) T is activated in D2 and then moves to D1 at 'begin'
+>> 2) T is activated and executed on D2
+> Right, but note that we should stick with RM terminology to avoid
+> confusion: activation is part of execution.
+
+Agreed, I was using the terms more informally
+
+> (I've never understood why activation is special -- that is, why the
+> activator should wait for notification from the activatee(s).
+> Strange.)
+
+I always assumed this was to catch a task failing during activation.
+Any exception raised during activation cannot really be caught by the task
+itself, so it must be caught by the 'parent'. Hence the 'parent' must wait until
+all 'child' tasks have got past the difficult age.
+
+The alternative would be to allow tasks to fail silently - activator would then
+not have to wait
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, January 31, 2011  8:27 AM
+
+I agree switching CPUs is undesirable, especially having just spent the time to
+initialize all of the nice local data structures of the task body on one CPU
+before reaching the "begin."  Also, the "Activation_Done" message is a "fire and
+forget" kind of message.  The subtask doesn't have to wait for any kind of
+acknowledgment from the activator -- it can just keep rolling along.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, January 31, 2011  10:05 AM
+
+> I always assumed this was to catch a task failing during activation.
+
+Yes, that's probably the reason.  But it's based on a broken aspect of the
+design: that exceptions in task bodies vanish by default.  I would have fixed
+that part of the design, instead.
+
+> Any exception raised during activation cannot really be caught by the
+> task itself, ...
+
+Well, it CAN be caught by the task itself: just move that decl part down into a
+block statement.  I'll bet most Ada programmers would make that transformation
+without even thinking about the weird activation semantics.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, January 30, 2011  11:12 PM
+
+I was filing old mail, and noticed an old suggestion that was never addressed.
+Back in July, Bob made a number of suggestions about AI05-0171-1. One of them
+was to rename the package to "Processors", since it makes just as much sense
+when there is only one processor. (At least to query how many processors there
+are.)
+
+Discussion of his other suggestions completely overwhelmed the package name, and
+no conclusion ever was made.
+
+I tend to agree with Bob here, in that "multi" is just noise. It makes the name
+longer than it needs to be.
+
+Any thoughts??
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 31, 2011   1:34 AM
+
+I aww insufficient reason to change.
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, January 31, 2011   3:55 AM
+
+My first reaction was that this was a good idea. But having browsed through the
+draft rat, it doesn't make the program text much shorter. Moreover, the
+commentary talks about multiprocessors quite a lot and the required
+functionality arises when there are several processors and was the cause of the
+introduction of the package. So I vote to leave it as is.
+
+Sometimes in English we always add the prefix such as multi. If my computer has
+several processors then I refer to it as a multiprocessor machine and not a
+processor machine. However, if I am talking about trains, I refer to a passenger
+train not a multipassenger train. Is that becuause a train for one passenger
+would be unusual?
+
+Brunel often had a private train, he being the only passenger. Here is a a
+little story. One night, Brunel galloped into Maidenhead on his way to London.
+The railway was only open between Paddington and Maidenhead so this would be in
+about 1838. He demanded a train and one was in steam, so he dashed off into the
+darkness having ascertained that no other trains were on the rails that night.
+Meanwhile, Babbage (yes the friend of Ada), arrived at Paddington. He was a
+senior consultant to Brunel and had free travel rights. He demanded an engine in
+order to go to Maidenhead. One was available. And the driver remarked that since
+there was no one about that night it didn't matter which track they used. A
+little later, both men to their horror saw the light of another train
+approaching. Luckily they were on different tracks. This made them think about
+the need for signals.  And I suppose if the worst had happened and both had been
+killed this would not be the ARG.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, January 31, 2011  6:30 AM
+
+> Sometimes in English we always add the prefix such as multi.
+
+OK, I am gruntled.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, January 31, 2011  8:20 AM
+
+"Processors" is fine with me.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Monday, January 31, 2011  9:25 AM
+
+I tend to agree as well. "Processors" is fine.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 31, 2011  9:34 AM
+
+The reason I prefer to keep the multi, is that this is all about multi-processing, it is not about more general features of processors such as their endianness, word length etc. So I think a name of processors is misleading.
+
+Let's look at the features:
+
+> package System.Multiprocessors is
+>    pragma Preelaborate (Multiprocessors);
+>
+>    type CPU_Range is range 0 .. 2 ** 16 - 1;
+>
+>    subtype CPU is CPU_Range range 1 .. CPU_Range'Last;
+>
+>    Not_A_Specific_CPU : constant CPU_Range := 0;
+>
+>    function Number_Of_CPUs return CPU;
+>    --  Number of available CPUs
+>
+> end System.Multiprocessors;
+
+All of this is about multiprocessing capability, it has nothing to do with
+giving specific information about processor characteristics. The child packages
+about locks are also all about multi-procesasing.
+
+Previously, I was sort of neutral on this, I have changed my mind, I think it is
+a mistake to change the name.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, January 31, 2011  9:58 AM
+
+> Previously, I was sort of neutral on this, I have changed my mind, I
+> think it is a mistake to change the name.
+
+I am convinced by Robert's arguments.  (Note that I'm the one who originally
+suggested the name change.)
+
+Another (fairly weak) argument: "multiprocessor" has some advertising value
+these days.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 31, 2011  10:11 AM
+
+Another (fairly weak) argument: GNAT has implemented it with the name
+Multiprocessor, so we would keep that name anyway, and just make the official
+one a renaming.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 31, 2011  10:12 AM
+
+> Another (fairly weak) argument: "multiprocessor" has some advertising
+> value these days.
+
+Actually that's a bit stronger than "fairly weak" for me
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 31, 2011  1:55 PM
+
+> The reason I prefer to keep the multi, is that this is all about
+> multi-processing, it is not about more general features of processors
+> such as their endianness, word length etc. So I think a name of
+> processors is misleading.
+
+It seems that we have no consensus for a change. (I count 4 in favor and 3
+against at this point.) Given that we can argue about naming pretty much
+forever, in the absence of a consensus, we should simply make no change and
+close the discussion. I so move.
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, January 31, 2011  2:41 PM
+
+Seconded.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Monday, January 31, 2011  2:41 PM
+
+I second. (And, just in case, count me in favor of multi.)
+
+****************************************************************
+
+From: Brad Moore
+Sent: Monday, January 31, 2011  8:56 PM
 
+I originally was going to go with Processors, but Roberts arguments persuaded me
+as well.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent