Re: Streams and Concurrency

[Mats Weber <Mats.Weber@elca-matrix.ch>]

dewar@gnat.com wrote:

> In any case, GNAT guarantees that blocking operations CAN
> be done within protected objects, of course you may get
> deadlock if you do obviously bad things, but certainly
> doing IO within a protected object is not such a bad thing,
> and this will work fine. We have many customers who depend
> on this guarantee.

I agree totally.

> Yes, yes, of course this is potentially non-portable, but
> it makes protected objects enormously more useful. Remember
> that there are two advantages of protected objects:
> 
> 1) possibility of more efficient implementation (I say
> possibility here because in fact there are many
> complications which result in less efficiency than you
> might have hoped for in the general case, and in any
> case some cases of agent tasks can be optimized in a
> corresponding efficient manner.

Are you talking about what DEC Ada and Verdix call passive tasks ?

> 2) preferable abstraction to a task in some situations
> 
> For my taste 2) is much more important than 1), and the
> restriction on blocking operations badly damages the use
> of 2).

I also see other reasons:

3) In order to protect objects with potentially blocking operations (a
socket, a pipe, etc.), you must either use a semaphore implemented as a
protected object and call the semaphore _twice_, once for locking and
once for unlocking, or you must use a task. Thus the promised
performance gain with protected objects is lost.

4) It is another case where the standard enforces things that no
compiler can check, neither at compile time nor at run time. Ada 83 had
incorrect order dependences in this category, where it was allowed to
raise Program_Error if it found one. Fortunately, this was removed from
Ada 95 and I think the restriction on blocking protected operations
falls in the same category.