Re: Unchecked_Conversion and task pointer.

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 12 Jul 2005 15:30:08 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:29tci5buk8ik.12z8wzs6awbnb.dlg@40tude.net...
>> On Mon, 11 Jul 2005 13:28:42 -0500, Randy Brukardt wrote:
>>
>>> Well, you can't ignore the prefix (it determines whether it is an internal
>>> or external requeue).
>>
>> This must be fixed anyway. There is no safe way to statically determine if
>> a requeue is internal (in Ada 95 it had a quite nasty consequences, like a
>> program which legality was dependent on whether at run-time a barrier was
>> open or not.)
> 
> This is confused. "Legality" is a compile-time concept; there is no such
> thing as legality being determined by something happening at runtime.
> Perhaps you meant something about whether an exception was raised, but that
> doesn't seem any different than an array bounds check.

The problem was, if I remember correctly, that a chain of requeues ending
in the starting point could be a bounded error or not depending on the
state of barriers. I suppose it is still so in Ada 200Y.

>> For class-wide objects the idea of protected actions should be refined: let
>> A extend B. Is a protected action on X of A, the same or a different action
>> on B(X)? What about B'Class(X), A'Class(X)? Further, for multi-methods, let
>> both tagged arguments resolve to the same type tag, but different objects.
>> Will it start two actions?
> 
> Ada 200Y doesn't allow extensions of task or protected types, specifically
> because the tasking operations don't compose well.

Some work will be required, but I cannot see any fundamental reason why
tasks and protected objects should not have classes, as well as any other
types, BTW. There was a proposal for protected objects:

http://www.cs.york.ac.uk/rts/papers/YCS_316_99.html

Task entries as primitive operations is more challenging, of course.

> You can make a set of
> rules, but any that are picked either will violate the expectations of the
> base type, or will be too restrictive on the extending type.

Type extension is not the only mechanism of subtyping.

> Moreover,
> however that is done will make the locking behavior of programs much harder
> to understand. Keeping all of the locking in one place is much better in
> terms of being able to analyze the effects. So your question cannot arise,
> because B necessarily is an interface, and interfaces have no "protected
> actions".

Quite formally: if you can call a procedure as an entry, then either there
are entries with no protected actions or each interface procedure has some
virtual protected action (that locks nothing.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de