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 15:27:58 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Matthew Heaney" Newsgroups: comp.lang.ada Subject: Re: How to avoid unreferenced objects (mutexes etc) Date: Mon, 14 Jan 2002 18:32:35 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3c3ee8c8.105408250@News.CIS.DFN.DE> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:18922 Date: 2002-01-14T18:32:35-05:00 List-Id: "Nick Roberts" wrote in message news:a1r6tr$slh9n$1@ID-25716.news.dfncis.de... > Well, I had no idea that Dmitry's critical section contained blocking calls. You seem to be objecting to the very idea of a semaphore type, claiming that all your synchronization needs can be done using a monitor-style protected object. That would be false, because a monitor implemented as a protected object is not allowed to make blocking calls. > My comments were made on the very reasonable assumption that it didn't. I > would suggest that it is unusual for a critical section to need to make > blocking calls, No, it is very common to have to make blocking calls in critical region. For example, I am writing a server in which client messages are logged to a file. However, multiple threads can be handling client requests, so the manipulation of the file object (to write the message) must by protected by a critical region. The critical region cannot be implemented as a monitor-style protected object, because the action is blocking. Hence the need for a semaphore-style protected object. > and generally desirable to remove blocking calls from critical sections wherever possible. I don't make blocking calls inside a critical region for my own amusement. I make a blocking call inside a critical region because I need to serialize access to a resource, and manipulation of the resource blocks. > Moreover, it is generally desirable to > reduce the execution time (both average and maximum, if possible) of a > critical section to a reasonable minimum. Motherhood and apple pie: no kidding. > No you don't. If your critical section must perform a blocking action, put > it in a task. E.g.: But the whole point is to use tasks as a unit of concurrency, not as a synchronization mechanism. That's why protected objects were invented. > The point is, it's generally better to use a > higher-level construct like this, because it generally gives the compiler > more opportunity to catch bugs. Ever hear the story about the king who asked both a computer programmer and an electrical engineer to design a toaster? http://www.shartwell.freeserve.co.uk/humor-site/elecvscomp.htm To use a high-level construct like a task to do a job that only requires a low-level primitive is an example of "abstraction inversion." Yes, a semaphore all by itself is dangerous, because you can forget to release it. But when used in conjuction with a controlled object, the release is guaranteed to happen, so there is no danger. > It may be a standard idiom, to some people, but that doesn't necessarily > make it the best approach. All you're saying here is that you don't like it. > Or, to put it another way, the standard idiom in this case doesn't seem to > address the problem of an exception leaving the resource in question in an > unstable state. Nor was it intended to. The idiom exists to guarantee that the Release operation of a semaphore is called, not matter what happens. If the exception leaves the resource in an "unknown state," that is a separate issue, quite orthogonal to the issue of synchronization. > Nor does it do anything to mitigate the effects of > accidentally omitting (or wrongly positioning) one of the seize or release > calls. Huh? When you use the controlled-object idiom, the seize and release calls are made for you by the controlled-object: Semphore : aliased Semaphore_Type; Critical_Section: declare Control : Control_Type (Semaphore'Access); begin end Critical_Section; The real problem is that Ada doesn't have a termination clause, like a finally clause in Java or in Win32 SEH. That's why these idioms are necessary: to work around that omission.