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,af960bc705aaf51b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-02-28 14:09:35 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!t-online.de!news-lei1.dfn.de!news-ber1.dfn.de!fu-berlin.de!uni-berlin.de!ppp-3-39.5800-11.telinco.NET!not-for-mail From: nickroberts@ukf.net (Nick Roberts) Newsgroups: comp.lang.ada Subject: Re: Complexity of protected objects Date: Thu, 28 Feb 2002 22:09:28 GMT Message-ID: <3c7e7c60.8192226@news.cis.dfn.de> References: <3C7A75F2.30503@worldnet.att.net> NNTP-Posting-Host: ppp-3-39.5800-11.telinco.net (212.1.154.39) X-Trace: fu-berlin.de 1014934172 8777711 212.1.154.39 (16 [25716]) X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:20608 Date: 2002-02-28T22:09:28+00:00 List-Id: On Mon, 25 Feb 2002 17:35:45 GMT, Jim Rogers strongly typed: >Using a protected object to read and write files is a clear >violation of the intention and recommendations for proctected >objects. Protected objects should be non-blocking. I/O is >always potentially blocking. It's perhaps a little sweeping to say "I/O is always potentially blocking". There may be certain rare cases where this is not so. But it will certainly always be so for reading or writing files, in practice. >You even have some potential blocking issues when storing an >AVL tree. If you dynamically allocate your AVL tree nodes you >have the possibility of running out of memory. This will either >result in a blocking situation, or a potential loss of data >in the AVL tree. I would suggest this is being ultra-cautious. In practice, dynamic memory allocation tends to be considered an 'honourary' non-blocking operation (even though this does actually fly in the face of the reality). It is certainly better to avoid any dynamic allocation in a protected subprogram if you easily can. Remember, you need to consider the practical consequences of a protected subprogram being blocked; the RM95 can only say what behaviour is or isn't guaranteed by all conforming Ada 95 implementations. In the case of running out of memory (for dynamic allocation), you may consider this to be a rare event, and a show-stopper anyway, and so not worth worrying about (in terms of how badly it may obstruct other tasks). I hasten to add that in some applications this attitude would be reckless. Consider, for example, virtual memory. Depending on the peculiarities of the Ada implementation and the target execution environment, it may be that the execution of a protected subprogram could cause a virtual memory 'page fault' at any point in its execution. Such page faults will typically cause I/O activity to occur (to swap a page in, swap a page out, allocate a page on secondary storage, or whatever). But I/O is 'potentially blocking'. Disaster! Well no, not really; as long as the 'block' does not last too long. Similar comments apply to pre-emptive scheduling environments and so on. >I would be inclined to use a simple protected buffer object to >communicate with one or more tasks for the reading and writing, >and another task to store the AVL tree. Protected operations allow >you to design a degree of asynchronisity into your system. They are >not expected to replace tasks for all uses. Agreed. Tony Gair wrote: >>(is this an oxymoron?). Well, I admire the shapeless solidity of the question. ;-) -- Nick Roberts