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
---------------------------------------------------------------------------