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 21:45:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.mathworks.com!wn3feed!worldnet.att.net!135.173.83.71!wnfilter1!worldnet-localpost!bgtnsc05-news.ops.worldnet.att.net.POSTED!not-for-mail Message-ID: <3C7F1559.5080304@worldnet.att.net> From: Jim Rogers User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Complexity of protected objects References: <3C7A75F2.30503@worldnet.att.net> <3c7e7c60.8192226@news.cis.dfn.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 01 Mar 2002 05:45:04 GMT NNTP-Posting-Host: 12.86.35.163 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1014961504 12.86.35.163 (Fri, 01 Mar 2002 05:45:04 GMT) NNTP-Posting-Date: Fri, 01 Mar 2002 05:45:04 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:20634 Date: 2002-03-01T05:45:04+00:00 List-Id: Dale Stanbrough wrote: > Jim Rogers wrote: > > >>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. >> > > Why is this? I see this as being a piece of programming advice, > - it's not a good idea to hold locks for a long time - but is > there any more to it than that? Are there some other consequences > of scheduling than that? It is good to understand why "it's not a good idea to hold locks for a long time". The first reason that comes to my mind is the need to avoid live locks and dead locks in your system. Note that this is an entirely different issue from queueing up protected entry calls because the entry guard is closed. Protected entries are used to communicate state as well as data between tasks. Blocking actions belong in separate tasks. Unless you are using FSU threads this should allow other tasks to procede while one task is blocked. Blocking during communication between tasks often has a cascading effect throughout a system. Jim Rogers