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

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

--- ai05s/ai05-0171-1.txt	2010/10/16 02:17:39	1.6
+++ ai05s/ai05-0171-1.txt	2011/02/08 08:21:06	1.7
@@ -97,7 +97,7 @@
 evaluated for each task object (see 9.1). The CPU value is then associated
 with the task object whose task_definition contains the pragma.
 
-A CPU pragma has no effect if it occurs immediately within the 
+A CPU pragma has no effect if it occurs immediately within the
 declarative_part of a subprogram_body other than the main subprogram;
 the CPU value is not associated with any task.
 
@@ -293,7 +293,7 @@
 evaluated for each task object (see 9.1). The CPU value is then associated
 with the task object whose @fa<task_definition> contains the pragma.
 
-A CPU pragma has no effect if it occurs immediately within the 
+A CPU pragma has no effect if it occurs immediately within the
 @fa<declarative_part> of a @fa<subprogram_body> other than the main subprogram;
 the CPU value is not associated with any task.
 
@@ -320,6 +320,171 @@
 
 !appendix
 
+From: Bob Duff
+Sent: Sunday, July 18, 2010  8:20 AM
+
+Minor comments on AI-171 and 167, processor affinity, etc.
+
+I think the package name should be Processors instead of Multiprocessors.
+Some computers still only have one, you know.  ;-)
+
+And I think all the "CPU"s should be "Processor" (e.g. Number_Of_CPUs -->
+Number_Of_Processors).  CPU seems sort of archaic, to me (room-sized computers
+with spinning tape drives), "processor" more modern.  Also, CPU seems illogical
+-- if there's more than one of it, how can it be "central"?
+
+****************************************************************
+
+From: Alan Burns
+Sent: Monday, July 19, 2010  8:17 AM
+
+Is this view generally agreed with? It would be useful to know before editing
+the text.
+
+I'm happy to make these changes.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, July 19, 2010  8:34 AM
+
+Bob's suggestions are fine with me.  I think also relevant is what terminology
+is used within the real-time community, if there is one that is used
+consistently.
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, July 19, 2010  11:45 AM
+
+We should certainly check consistency of terminology. It is sometimes the case
+that historic terminology is used even though the technology has moved on. Thus
+the states onhook and offhook are I believe still used in telecommunications
+although it is a long time since I saw a telphone with a hook.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, July 19, 2010  12:17 PM
+
+I have no significant problem with this, but Ada already has the concept of
+CPU_Time (see D.14(11/2) etc.) Probably that should have been called
+Processor_Time, but it seems too late to do that. (We could of course add a
+subtype of Processor_Time called CPU_Time and add duplicate constants to
+Ada.Execution_Time to compatibly change the names of this type and the
+associated constants, but that seems way over the top.)
+
+We did discuss this at the ARG meeting in St. Petersburg; here's the notes:
+
+Is CPU appropriate; should this be "processor"? CPU is ancient but short.
+Someone suggests "core". We don't seem to have a conclusion. Randy notes later
+that D.14 uses "CPU_Time".
+
 ****************************************************************
 
+From: Bob Duff
+Sent: Monday, July 19, 2010  3:16 PM
+
+> I have no significant problem with this, but Ada already has the
+> concept of CPU_Time (see D.14(11/2) etc.) Probably that should have
+> been called Processor_Time, but it seems too late to do that.
+
+Hmm.  Somehow "CPU time" seems fine to me, and "processor time" seems odd.  But
+"number of CPUs" seems archaic and illogical, whereas "number of processors"
+seems fine.
+
+I won't claim to have any logical reason for this opinion.  ;-)
+
+>...(We could of course add a
+> subtype of Processor_Time called CPU_Time and add duplicate constants
+>to  Ada.Execution_Time to compatibly change the names of this type and
+>the  associated constants, but that seems way over the top.)
+>
+> We did discuss this at the ARG meeting in St. Petersburg; here's the notes:
+>
+> Is CPU appropriate; should this be "processor"? CPU is ancient but short.
+> Someone suggests "core". We don't seem to have a conclusion. Randy
+> notes later that D.14 uses "CPU_Time".
+
+OK, well it's certainly not worth a huge argument.  Let's decide one way or
+'tother, so GNAT can go ahead and implement it.
+
+One more question (sorry if I'm being a trouble maker...):
+Why is it System.Multiprocessors (or as I suggested System.Processors)?
+Why not Ada.Processors?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, July 19, 2010  3:32 PM
+
+> Hmm.  Somehow "CPU time" seems fine to me, and "processor time" seems
+> odd.  But "number of CPUs" seems archaic and illogical, whereas
+> "number of processors" seems fine.
+>
+> I won't claim to have any logical reason for this opinion.  ;-)
+
+I agree with Bob and hold the same slightly illogical view point
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, July 19, 2010  3:36 PM
+
+> One more question (sorry if I'm being a trouble maker...):
+> Why is it System.Multiprocessors (or as I suggested System.Processors)?
+> Why not Ada.Processors?
+
+We debated this.  The number of processors seems closer to
+target-environment-related things like the size of the memory and the bits per
+word than to something that is language-related such as Ada.Tags or Ada.Text_IO.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, July 19, 2010  3:40 PM
+
+Isn't this a low-level thing more like an Address than something higher-level?
+Surely the majority of Ada programs will work just fine without changing the
+CPU/processor affinities. That seems to be something that would be done only for
+critical tuning, much like Address is only used for low-level hardware access.
+
+Assuming that you agree with this, then it seems appropriate for it to be in
+System, as opposed to Ada. After all, you could argue that Address should be in
+Ada as well: every computer has addresses.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, July 19, 2010  4:02 PM
+
+> Isn't this a low-level thing more like an Address than something
+> higher-level? Surely the majority of Ada programs will work just fine
+> without changing the CPU/processor affinities. That seems to be
+> something that would be done only for critical tuning, much like
+> Address is only used for low-level hardware access.
+
+Actually no, the switch from one processor to two has profound semantic
+implications, and I can easily see a program that only runs on a monoprocessor
+using this function to guard itself.
+
+> Assuming that you agree with this, then it seems appropriate for it to
+> be in System, as opposed to Ada. After all, you could argue that
+> Address should be in Ada as well: every computer has addresses.
+
+I think that everything should be in Ada, but given the contrary choice of the
+past, system seems more consistent.
+
+****************************************************************
+
+From: Alan Burns
+Sent: Monday, July 20, 2010  2:28 AM
+
+The Linux literature talks mostly of CPU affinity, with CPUSETS (or
+CPU_Sets) being used
+extensively.
+
+So I think given the comments so far, I'll stay with CPU.
+
+****************************************************************
 

Questions? Ask the ACAA Technical Agent