LRM question - access types and concurrency 
Author Message
 LRM question - access types and concurrency

Here is a question for the language lawyers.

First, recall Ada LRM 3.8(3)
  "The objects designated by the values of an access type
   form a collection implicitely associated with the type."

The question is:
  Can multiple tasks allocate objects from the same collection safely,
without having to serialize calls to new and unchecked_deallocation ?
Are implementations responsible for ensuring that the shared variables
(heap allocation state variables etc) implicit in the access type
declaration are correctly handled in the presence of concurrency ?
Or is it the programmer's responsibility to serialize calls to allocators
for fear they may be interrupted during critical sections ?
Or is it unspecified and therefore erroneous if it just happens to work?

I have never found a mention of this in the LRM and have always wrapped
allocate/deallocate tasks around "new" in those cases.  
(or avoided global access types) Was I being paranoid?

  Consider
    package global_types is
      type crud is access integer;
    end global_types;

    ...
    task body A is
    begin
      crudptr := new crud;
      ...
      free (crudptr); -- unchecked deallocation
    end A;

    task body B is -- the same

   ----- Alternative -- Is this necessary ? -----

   package paranoid_global_types is
     type crud is access integer;
     task crud_mgr is
       entry create (bozo : in out crud);
       entry free (bozo : in out crud);
     end crud_mgr;
   end paranoid_global_types;

   ....
   task body A is
   begin
     paranoid_global_types.crud_mgr.create (crudptr);
     ...
     paranoid_global_types.crud_mgr.free (crudptr);
   end A;

   task body B is -- the same

-----------------------------------------------------------------------

Software Productivity Consortium     UUNET:    ...!uunet!software!blakemore
2214 Rock Hill Rd, Herndon VA 22070  Bellnet:  (703) 742-7125



Sat, 12 Dec 1992 10:51:19 GMT  
 LRM question - access types and concurrency
Quote:

>Here is a question for the language lawyers.

>The question is:
>  Can multiple tasks allocate objects from the same collection safely,
>without having to serialize calls to new and unchecked_deallocation ?

I have always assumed they cannot.

Quote:
>Are implementations responsible for ensuring that the shared variables
>(heap allocation state variables etc) implicit in the access type
>declaration are correctly handled in the presence of concurrency ?

From everything I have ever read or discussed, implementations are not
required to do so.

Quote:
>Or is it the programmer's responsibility to serialize calls to allocators
>for fear they may be interrupted during critical sections ?

I believe it is.

Quote:
>Or is it unspecified and therefore erroneous if it just happens to work?

I suspect it's erroneous.
Quote:

>I have never found a mention of this in the LRM and have always wrapped
>allocate/deallocate tasks around "new" in those cases.  

In my experience, you've done the right thing, but I'd love to see an
authoritative response posted!

Quote:
>(or avoided global access types) Was I being paranoid?

I think it's wise to be paranoid around tasking. A lot of stuff can be
deduced from the LRM where the LRM is silent (e.g. the requirement for
preemption if multiple priorities are supported); interpretations from the
AdaBoard (ARG, whatever it's called) have settled some of the issues.
I don't think anything can be deduced about access types; my guess is that
no serialization of allocations is built in.  I don't recall seeing
an interpretation on this issue specifically, but I may have missed it.

My guess is that if the LRM is silent on a particular issue of protection
in the presence of tasking, one better not count on it. I hope it'll be
tightened up in the LRM for Ada9x.
---------------------------------------------------------------------------
Prof. Michael Feldman
Department of Electrical Engineering and Computer Science
The George Washington University
Washington, DC 20052
+1-202-994-5253

---------------------------------------------------------------------------



Sun, 13 Dec 1992 00:43:38 GMT  
 LRM question - access types and concurrency
Quote:


>>  Can multiple tasks allocate objects from the same collection safely,
>>without having to serialize calls to new and unchecked_deallocation ?
>I have always assumed they cannot.

     Professor Feldman's assumption is probably safer, but I've always
assumed that the simplest reading of the LRM holds, unless the designers
either made an explicit exception or a mistake.  Section 4.8 says

     "The evaluation of an allocator creates an object and yields an access
value that designates the object."

In a cursory pass through the LRM's index and cross-references I haven't
found any relaxation of this definition in the case of tasking.  There-
fore if two tasks execute allocators on the same collection simultaneously,
two objects must be properly created and two access values properly yielded.

Quote:

>My guess is that if the LRM is silent on a particular issue of protection
>in the presence of tasking, one better not count on it.

Again, this is probably the safest approach.  If my interpretation is cor-
tect, does the ACVC test it?  I doubt it.

                                  Charlie Sampson



Sun, 13 Dec 1992 04:04:15 GMT  
 LRM question - access types and concurrency

Re: Allocators and tasking.

The programmer need only worry about declared variables which are shared
between tasks.  An access collection is not considered an explicitly
declared variable in this sense.

The implementation must worry about all "hidden" shared data.

Therefore, an implementation must protect its run-time data structures
from simultaneous access.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138



Sun, 13 Dec 1992 23:53:00 GMT  
 LRM question - access types and concurrency

Quote:

>The programmer need only worry about declared variables which are shared
>between tasks.  An access collection is not considered an explicitly
>declared variable in this sense.
>The implementation must worry about all "hidden" shared data.
>Therefore, an implementation must protect its run-time data structures
>from simultaneous access.

So what about the built-in I/O packages? Is it safe for multiple tasks
to be issuing, say, Put_Line calls without worrying about synchronization?

[Aside: I think I know what Tucker's response will be; he'll say that the
 I/O packages are just like user packages, they just happen to come with
 the compiler, so they are not required to be "thread-safe."]

I bring this up because it has been a repeated thorn in my side over the
years. I've always felt that, at the very least, the built-in I/O packages
should provide some means of requesting synchronization in the face of
tasking. Maybe a form string parameter?

Quote:
>S. Tucker Taft
>Intermetrics, Inc.

-- Jerry "RTS hack" Callen



Mon, 14 Dec 1992 21:34:57 GMT  
 LRM question - access types and concurrency
 >
 >Re: Allocators and tasking.
 >
 >The programmer need only worry about declared variables which are shared
 >between tasks.  An access collection is not considered an explicitly
 >declared variable in this sense.
 >
 >The implementation must worry about all "hidden" shared data.
 >
 >Therefore, an implementation must protect its run-time data structures
 >from simultaneous access.
This comes as very good news. Is there an AI that governs it, or is it
part of the folklore somewhere? Is it tested in the ACVC?


Tue, 15 Dec 1992 11:51:37 GMT  
 LRM question - access types and concurrency
Quote:

>                                Is it tested in the ACVC?

It sounds very simple. Why dont you write a test for it?


Tue, 15 Dec 1992 21:25:15 GMT  
 LRM question - access types and concurrency
Quote:


>>                                Is it tested in the ACVC?
>It sounds very simple. Why dont you write a test for it?

Well, I don't think it's a simple as all that. What needs to be tested is
whether the allocator is safe in the presence of a run time system in which
tasks can be arbitrarily interrupted (pre-empted, whatever). Do you have a
good idea for a program that can create these conditions, i.e. that is
such that we can control the timing precisely enough to guarantee that the
two tasks executing allocator calls will be interrupted precisely in the
middle of their calls?

I am reassured by Tucker Taft's assertion that an implementation has to be
sure its runtime data structures aren't "corrupted" in tasking situations.
I asked about the ACVC because, since I've never seen that assertion in
writing "officially," I wonder what the authority is for it.



Wed, 16 Dec 1992 01:30:08 GMT  
 LRM question - access types and concurrency
Quote:

>So what about the built-in I/O packages? Is it safe for multiple tasks
>to be issuing, say, Put_Line calls without worrying about synchronization?

     My answer is a variant of my followup to the original question:  A pro-
grammer doesn't have to worry about synchronizing calls to the I/O procedures
provided no pair of tasks is operating on the same file; otherwise the imple-
mentation will not satisfy the semantics of the LRM ("Put_line calls the
procedure Put for the given string ...").

     If two tasks are accessing a common file, then all bets are off.  The
file becomes a shared resource and synchronization is definitely the program-
mer's responsibility.  In the case of text I/O, Put_line is defined, ulti-
mately, in terms of repeated calls on Put for single characters.  With this
definition, interlacing of strings is almost guaranteed.

     Should the definition be changed?  It's not easy because there is no
obvious useful way to synchronize the tasks.  Guaranteeing private access
to the file during output of words, sentences, lines, and paragraphs are
all clearly inadequate.  (How often is a report with alternate paragraphs
coming from two different sources useful?)

                              Charlie Sampson



Wed, 16 Dec 1992 05:55:31 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Ambiguity in Ada LRM about private types and type conversions

2. Inheritance of abstract types: accessing the parent type (F2003 standard question)

3. type is access cf type is access all?

4. LRM:3.10.1(5), Can't reference incomplete type compile error

5. diff Ada83-LRM Ada9X-LRM

6. access type question (maybe a little silly)

7. Conversion of Access Types Question

8. A question about access types and assignment

9. Access-To-Object-Type question.

10. Tasking Question.... (access types/record structures/etc)

11. Access type question ...

12. Ada question: access types

 

 
Powered by phpBB® Forum Software