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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9d303864ae4c70ad X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-04-17 07:14:30 PST Path: archiver1.google.com!news1.google.com!news.glorb.com!news.moat.net!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 17 Apr 2004 09:14:29 -0500 Date: Sat, 17 Apr 2004 10:14:29 -0400 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Reprise: 'in out' parameters for functions References: <5ad0dd8a.0404090512.15af2908@posting.google.com> <5ad0dd8a.0404091828.6e79bb4e@posting.google.com> <8Oadneu6eY9pweDdRVn-hA@comcast.com> <5ad0dd8a.0404151752.4f598e1a@posting.google.com> <5ad0dd8a.0404160338.5a1c9116@posting.google.com> <1080a21p0nn482f@corp.supernews.com> <5ad0dd8a.0404161415.220cce54@posting.google.com> <-9qdnUKOH_DVGx3dRVn-ug@comcast.com> <5ad0dd8a.0404170342.6a916b9b@posting.google.com> In-Reply-To: <5ad0dd8a.0404170342.6a916b9b@posting.google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.90.114 X-Trace: sv3-6SQLzRkv3NySE+UTzoRtTZcAdY+qOZMpZ6vn435MlR3qaw1FFre1D7b/Bjt1xQZYDGGDcYX9M9FHlDm!XFChdwY96jz2uDtGfwEEss9Whn9b7wqPFTBHBgoMVXu2/6XeJ2q/o3IVdB/Pgw== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:7256 Date: 2004-04-17T10:14:29-04:00 List-Id: Wojtek Narczynski wrote: > Another problem of this kind is that the lock owner thread can get > preempted by the operating system. This is more frequent, but less > devastating than a page fault. There are "tricks" to minimize this. Even if I am programming at system independent level, I try to insure that all pages that may be needed inside a lock have been referenced outside the lock first. In a formal sense, this won't improve things, but in practice it can make the difference between good performance and bad. The best of all possible worlds is a compiler that wraps protected actions in an interrupt-deferred region. Like all real-time features, this is a two-edged sword, but one you have to use in some cases. > Okay, practitioners speaking, so I will just listen. Should I ask for > a refunt for "Transaction Processing: Concept and Techniques" by > J.Gray & A. Reuter? :-) Theory is important, so is practice. Without the theory you don't know what is and isn't correct in a formal sense. But in real-time programming, too late is just as bad as any other error, and it is an emergent property of the whole system. It is very frustrating to design a race free and deadlock free system, then find that to meet the performance requirements you have to violate some of the assumptions necessary to make the system deadlock free. Yes, you can often go "back to the drawing board" and come up with a more complex solution that works and meets the requirements. But far more often, you end up with a solution which is only deadlock free because it occasionally aborts lower priority transactions. -- Robert I. Eachus "The terrorist enemy holds no territory, defends no population, is unconstrained by rules of warfare, and respects no law of morality. Such an enemy cannot be deterred, contained, appeased or negotiated with. It can only be destroyed--and that, ladies and gentlemen, is the business at hand." -- Dick Cheney