Re: Advantages

["Robert I. Eachus" <rieachus@comcast.net>]

Brian May wrote:

> The implication of what you say is you can't have a deadlock in Ada
> across different packages, that will compile, if you use protected
> objects in this manner to access variables
> 
> Not true!

As others have already pointed out.  True.  The wording of the standard 
is subtle to allow for things like asynchronous I/O operations, or 
protected operations in the library distributed with the compiler that 
'know' about special properties of the target system.  Or more 
important, OS calls that are potentially blocking, but where the 
protected object is coded so that the call is only made when it cannot 
block.

As Randy says, the wording of the message from GNAT is not as clear as 
it could be:  "You blockhead! This program can deadlock!"

That message, of course, is not appropriate in some of the special cases 
where the user can tell that deadlock/Program_Error will never occur. 
And of course "can" not "will" in the message is correct--the compiler 
can't tell if the operations that will deadlock will be called--at least 
not at compile time.

Of course, if you are designing real-time systems, this is what you 
should care about.  The Ada compiler cannot tell you that your program 
will deadlock.  What it can tell you, by the absense of warnings, is 
that your program will not have any deadlocks directly involving 
protected objects.  There are similar rules elsewhere in the language 
involving tasks.

> I would imagine that there are other cases where the compiler can't
> warn you.

No, the compiler can always warn you.  Of course, if you want, you can 
use protected objects to implement P and V, then wrap potentially 
blocking actions inside the semaphores implemented that way.  But that 
is going out of your way to get back to the situation without Ada 
protected objects.

The intent in Ada really is that protected objects used correctly will 
not create deadlocks.  Used correctly of course, means among other 
things absent bounded errors.  If you want to encapsulate a potentially 
blocking operation in a protected object, that is what entries and entry 
barriers are for.  You either have an entry where the barrier condition 
is that the potentially blocking action inside the entry will not block, 
or you can use a requeue statement if you determine that the action will 
block.  Either way, the user of the abstraction can use a timed or 
conditional entry call, so that the caller will either not block, or not 
block for more than a predetermined time.

-- 

                                           Robert I. Eachus

"The flames kindled on the Fourth of July, 1776, have spread over too 
much of the globe to be extinguished by the feeble engines of despotism; 
on the contrary, they will consume these engines and all who work them." 
-- Thomas Jefferson, 1821