From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6009c73a58f787a0 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-01-16 07:05:37 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) Newsgroups: comp.lang.ada Subject: Re: How to avoid unreferenced objects (mutexes etc) Date: Wed, 16 Jan 2002 15:05:35 GMT Message-ID: <3c45865f.2709203@News.CIS.DFN.DE> References: <3c3ee8c8.105408250@News.CIS.DFN.DE> <3c429d1c.2624281@News.CIS.DFN.DE> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) X-Trace: fu-berlin.de 1011193535 32201893 212.79.194.111 (16 [77047]) X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:18969 Date: 2002-01-16T15:05:35+00:00 List-Id: On Tue, 15 Jan 2002 18:59:16 -0000, "Nick Roberts" wrote: >"Dmitry A. Kazakov" 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