Re: Safety of unprotected concurrent operations on constant objects

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Brad Moore <brad.moore@shaw.ca> writes:

> However, it might make sense to specify certain primitive subprograms of
> a type as being task safe.

What exactly do you mean by "task safe", either for a type, or for
a subprogram?  E.g. if Element is task safe, does that mean calls
to Element are atomic with respect to each other?  If both Element
and Replace_Element are task safe, does that mean calls to Element
and Replace_Element are atomic; i.e. if one task calls Element,
and another calls Replace_Element, those two calls are serialized?

Why primitive subprograms?  What about class-wide subprograms
declared in the same package?

Does task safety imply absence of deadlock?

Suppose we have an atomic increment function (calls to it are
serialized), and Counter is initially 0, and one task does
"X := Incr (Counter);" and another task does "Y := Incr (Counter);".
A third task waits for those two to terminate, and then calls 
procedure P, which prints X followed by Y.  Is P task safe?

If the comment on P says "-- This prints 1 followed by 2.",
you've got a race condition.  But what if the comment says
"-- This prints 1 and 2, in either order." -- does that
make it task safe?

I understand task safety in an informal way, but I'm not sure
how to decribe it formally.  And if the definition depends on
the intent of the programmer (perhaps expressed in comments),
we can't expect a compiler to check it.  ;-)

- Bob