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-13 05:11:00 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!nntp.abs.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!newscon02.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr14.news.prodigy.com.POSTED!not-for-mail From: tmoran@acm.org Newsgroups: comp.lang.ada Subject: Re: How to avoid unreferenced objects (mutexes etc) References: X-Newsreader: Tom's custom newsreader Message-ID: NNTP-Posting-Host: 67.112.202.184 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr14.news.prodigy.com 1010910098 ST000 67.112.202.184 (Sun, 13 Jan 2002 03:21:38 EST) NNTP-Posting-Date: Sun, 13 Jan 2002 03:21:38 EST Organization: Prodigy Internet http://www.prodigy.com X-UserInfo1: Q[RGGTSDZRRQBQH]]RKB_UDAZZ\DPCPDLXUNNH\KMAVNDQUBLNTC@AWZWDXZXQ[K\FFSKCVM@F_N_DOBWVWG__LG@VVOIPLIGX\\BU_B@\P\PFX\B[APHTWAHDCKJF^NHD[YJAZMCY_CWG[SX\Y]^KC\HSZRWSWKGAY_PC[BQ[BXAS\F\\@DMTLFZFUE@\VL Date: Sun, 13 Jan 2002 08:21:38 GMT Xref: archiver1.google.com comp.lang.ada:18857 Date: 2002-01-13T08:21:38+00:00 List-Id: > and generally desirable to remove blocking calls from > critical sections wherever possible. Sometimes the "critical section" quite reasonably could last a long time - when it's doing an IO operation using an IO channel, for instance. That can be long, lots of other things can legitimately run, but there better not be anyone else trying to use that same IO channel at the same time. Claw.Sockets.Read, for instance, uses this idiom, and a Read could block a particular socket for quite a while. >address the problem of an exception leaving the resource in question in an >unstable state. Nor does it do anything to mitigate the effects of >accidentally omitting (or wrongly positioning) one of the seize or release >calls. The original question was about: > Temp : Lock (Mutex_of_a_resource'Access); >begin > ... -- Safe access to the resource >end; -- Mutex is released even if an exception propagates and clearly there is no danger of omitting or wrongly positioning anything, or of problems with an exception. In fact Temp : Lock (Mutex_of_a_resource'Access); Something : Positive := Some_Value; would even be safe if Some_Value was negative, which is not a case a local (after the "begin") exception handler would catch. Once Initialize(Temp) has been called a matching Finalize(Temp) call is guaranteed. > > The technique shown using a Limited_Controlled type to > > automatically seize and release the semaphore is a standard Ada95 idiom. And a good idiom, IMHO.