Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 29 Feb 2012 10:28:35 -0600
Message-ID: <4F4E522A.50405@SPAM.comp-arch.net>
Date: Wed, 29 Feb 2012 08:28:26 -0800
From: "Andy (Super) Glew" <andy@SPAM.comp-arch.net>
Reply-To: andy@SPAM.comp-arch.net
Organization: comp-arch.net
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: M68k add to memory is not a mistake any more
References: <ggtgp-8D1AEA.03180231012012@netnews.mchsi.com> <4F4BBB9B.7050300@SPAM.comp-arch.net> <jigmkj$k9o$1@gosset.csi.cam.ac.uk> <4F4D987B.5060007@SPAM.comp-arch.net> <jiktqp$rru$1@gosset.csi.cam.ac.uk>
In-Reply-To: <jiktqp$rru$1@gosset.csi.cam.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 16
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-scFktZno9PHivuefwct0niCE+9eZr17Iu6SvX/jh/I9/7pVtc1nzB2lWMOHhM3NiGLOYWRLffr4U6SX!WyvohlsYsROK5eg9sNTJeqq0d8JI08cwsIu1Mn1SN5SXZKOUWSamAy/0kc6m
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
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.3.40
X-Original-Bytes: 2116
Xref: x330-a1.tempe.blueboxinc.net comp.arch:6177

On 2/29/2012 2:14 AM, nmm1@cam.ac.uk wrote:
> In article<4F4D987B.5060007@SPAM.comp-arch.net>,
> Andy (Super) Glew<andy@SPAM.comp-arch.net>  wrote:
>>
>>> The question of whether such a thread is holding a lock is solved better
>>> under this scheme, because at least you can recover the lock when the
>>> process is killed.  Systems that have had uncooperative lock recovery
>>> have never been a great success.
>>
>> What sort of lock recovery does UNIX / Linux have, generically?
>
> Easy.  Locks are optional - just do the operation unlocked.  It might
> even work - sometimes ....

Yes, that's the UNIX way: they removed all of the implicit locking, 
etc., that older OSes provided to make programs more likely to be correct.