Re: How to avoid unreferenced objects (mutexes etc)

[dmitry@elros.cbb-automation.de (Dmitry A. Kazakov)]

On Tue, 15 Jan 2002 18:59:16 -0000, "Nick Roberts"
<nickroberts@adaos.worldonline.co.uk> wrote:

>"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
>news:3c429d1c.2624281@News.CIS.DFN.DE...
>
>> ...
>> Maybe I should describe the problem. There is a communication channel
>> implemented as a tagged type. The base type provides low-level I/O
>> operations. It has read and write tasks serving as monitors. The
>> problem is with the derived types [potentially an arbitrary number of
>> them]. They extend the base type and  provide layered high-level
>> operations.
>
>I'm not too keen on this approach, because this way the higher levels do not
>'hide away' the lower-level interface. Normally, it would be better for a
>distinctly higher-level interface to be based on a different type (not a
>derived one).

Well, you can derive from the base in the private part and expose
operations you want to keep visible using wrappers implemented via
renaming in the body.

However, I always wished Ada having an ability to disallow primitive
operations. Like:

type Unordered is new Integer;
function ">" (Left, Right : Unordered) is abstract; -- Disallow ">"

>> Some of them must lock the channel [either read or write
>> one]. A "natural" solution would be to extend monitors, but alas tasks
>> are not tagged.
>
>But the tagged type could contain a component of a task type.

Yes, and another problem as well. Finalize is called *after* all task
components has been terminated. So when the object is being destroyed
you cannot notify tasks about that. You must use pointers to tasks if
you need a "prepare-to-die" notification.

>> An untagged solution requires an increasing number of
>> wrapping subroutines [thus run-time penalty].
>
>I really don't understand why there should be a greater time penalty for
>this solution. I think possibly this is a misunderstanding that lies at the
>heart of your problems.

Maybe the penalty is not very high, but writting dozens of wrappers is
disgusting.

>> A genericity-based
>> solution produces a combinatoric explosion of packages used as the
>> parameters for other packages etc. They must be instantiated at the
>> library level. In other words it is a mess.
>
>I don't really see generics being directly relevant to the problem here.

You can make package implementing some interface layer generic with a
lower level package as the formal parameter.

>> So I chose the lesser evil = mutexes with all that nasy problems of
>> error recovery, you have pointed. I really do not like it.
>
>Please find below an outline skeleton of what a simple communications
>hierarchy might look like in Ada. It is merely a guess at what you need, and
>it even then is merely a suggestion of how to do it.

[ driver example snipped ]

The difference is that with a driver you always know the interface:
Open/Read/Write/Close. The protocols we must implement are more
complex. Additionally one should have an ability to replace any part
of the hierarchy. For instance, low level: transport [like sockets vs.
RS323], middle level: time synchronization protocol, high level client
vs. server. Of course this ideal is reachless, so I am considering a
which "local optimum" to take. (:-))

Regards,
Dmitry Kazakov