CVS difference for ai12s/ai12-0415-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0415-1.txt

--- ai12s/ai12-0415-1.txt	2020/12/04 07:43:36	1.1
+++ ai12s/ai12-0415-1.txt	2020/12/04 07:59:30	1.2
@@ -11,10 +11,10 @@
 
 We generalize the aspect Parallel_Calls (see 9.10.1) to apply to
 immutably limited or formal limited types, and to access-to-object
-types.  If specified for an immutably or formal limited type, this means
+types. If specified for an immutably or formal limited type, this means
 that Parallel_Calls applies to all primitive subprograms of the type,
 with the exception of the Initialize and Finalize operations for limited
-controlled types.  If specified for an access type, it means that the
+controlled types. If specified for an access type, it means that the
 storage pool is a standard storage pool, or that Parallel_Calls applies
 to the Allocate, Deallocate, and Storage_Size operations of the type of
 the access type's storage pool.
@@ -23,21 +23,21 @@
 
 In analyzing the side effects of allocation and deallocation on storage
 pool objects. the issue arose of whether such effects are safe from
-conflicts due to unsynchronized references to shared variables.  It has
+conflicts due to unsynchronized references to shared variables. It has
 generally been presumed that allocation and deallocation are thread safe
 for "standard" storage pools, meaning that allocators for the same
 access type (with such a storage pool) are safe even if they occur
-concurrently in different threads of control.  But there is no way to
+concurrently in different threads of control. But there is no way to
 specify that a user-defined storage pool has a similar level of thread
 safety.
 
 Recognizing this problem for user-defined storage pools led to a
 recognition that the problem is more general, in that there is no way to
 declare that an object of a given type can safely be operated on
-concurrently from multiple threads.  Note that language-defined
+concurrently from multiple threads. Note that language-defined
 subprograms are required (in Annex A(3/5)) to provide thread safety, but
 only if the objects being operated on are *different*, so this is really
-talking about side effects on globals, if any.   And of course protected
+talking about side effects on globals, if any.  And of course protected
 operations and task entries can safely be called concurrently on the
 same protected/task object (though even with these there is still
 the possibility that such concurrent calls conflict because they have
@@ -111,13 +111,13 @@
 
 We considered defining a new aspect for this purpose, but felt it was
 better to build on the Parallel_Calls aspect, as it would be confusing
-to have two closely related concepts using different aspects.  We
+to have two closely related concepts using different aspects. We
 considered changing the name of the aspect to "Synchronizing" but felt
 that might imply that some kind of lock was involved, when really all we
 are promising is that parallel calls are safe.
 
 We make an exception for Initialize and Finalize as these are generally
-never invoked implicitly in parallel for a limited controlled type.  The
+never invoked implicitly in parallel for a limited controlled type. The
 user might invoke one of these explicitly, but there is generally no
 guarantee that concurrent finalization or initialization even of a
 "trivial" controlled object is guaranteed to be implemented in a thread
@@ -126,7 +126,7 @@
 We presume that all operations on protected and task types support
 parallel calls, though it is conceivable that a user could construct one
 that would be unsafe, but we see no reason to try to account for such an
-unlikely special case.  A friendly implementation could provide a warning
+unlikely special case. A friendly implementation could provide a warning
 if it were to detect such a situation.
 
 !examples

Questions? Ask the ACAA Technical Agent