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-14 01:42:11 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!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: Mon, 14 Jan 2002 09:42:08 GMT
Message-ID: <3c429d1c.2624281@News.CIS.DFN.DE>
References: <3c3ee8c8.105408250@News.CIS.DFN.DE>
 <a1o2h1$sfe3f$5@ID-25716.news.dfncis.de>
NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111)
X-Trace: fu-berlin.de 1011001328 30764540 212.79.194.111 (16 [77047])
X-Newsreader: Forte Free Agent 1.21/32.243
Xref: archiver1.google.com comp.lang.ada:18890
Date: 2002-01-14T09:42:08+00:00
List-Id: <comp.lang.ada>

On Sat, 12 Jan 2002 01:11:43 -0000, "Nick Roberts"
<nickroberts@adaos.worldonline.co.uk> wrote:

[...]

>The general idea is that a mutex is a low-level synchronisation construct,
>and Ada provides a higher-level construct (protected objects) that takes
>away much of the pain and danger of using mutexes directly.

Absolutely. So my suspicion goes. Or else, there must be something
fundamentally wrong [in design] if unused objects are *really*
required. It clearly indicates a *problem*.

I would prefer a monitor based solution as Jeffrey Carter suggested,
but I just failed to design it [properly].

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. 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. An untagged solution requires an increasing number of
wrapping subroutines [thus run-time penalty]. 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.

So I chose the lesser evil = mutexes with all that nasy problems of
error recovery, you have pointed. I really do not like it.

Regards,
Dmitry Kazakov