Path: csiph.com!x330-a1.tempe.blueboxinc.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!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 09 Apr 2011 11:29:13 -0500 Date: Sat, 09 Apr 2011 09:29:10 -0700 From: Patricia Shanahan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: Threads and statics References: <905p9gFpuoU1@mid.individual.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <5cCdnewnF63EFD3QnZ2dnUVZ_j2dnZ2d@earthlink.com> Lines: 51 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 75.8.126.96 X-Trace: sv3-J5jqNeWb6+v8C7sH4ZC0h2ZBHd6DizQlte7n5AzMxSmIsmzQCjueayXBveQEu61xFo36petmbqjFk8U!gaJgOEg/iNoKZboohBz4KO87kPUnQNGUuvXjI1f98JHR+2r7Gi4lYGSjFTfJN4TP75QBt/ZUGKUB!fQFISt+RQHtGIy3ueVULiYjw6W/2tx1ITvl+5AspjUQ= 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: 3454 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3012 On 4/9/2011 9:08 AM, Stefan Ram wrote: > Eric Sosman writes: >> manipulates). Make sure the data is always seen in a consistent >> state, except perhaps by the *one* thread that's in the act of >> changing it; then you'll have a correct program. > > It still could have potential deadlocks. > > IIRC, deadlocks can happen when two threads each need two > resources and already have obtained access to one of them. > Each thread now waits for the other one to release the > other resource. > > I have little knowledge about multithreading, but from this > it seems that one can avoid deadlocks as long as one can > avoid situations where more than one resource needs to be > obtained for exclusive access at the same time. That is the trivial case, and is related to one of the simpler deadlock avoidance strategies: Establish a partial order among all lockable resources. Locking B while holding A is safe if, and only if, A precedes B in the partial order. > > From what I heard, for any realistic project, it is > impossible to be sure that one got this right. For example, > a program was written by experts in multithreading and then > showed a deadlock the first time after several years of use. > Successful multi-threading is most likely with a defense in depth. Testing alone is not enough - a bug that happens once per thousand hours of running some type of workload is difficult to find through testing, but would cause a deadlock once per system per month at a site with the right sort of workload. There is often a temptation during testing to ignore failures that only happen once and cannot be reproduced. If the development team gives in to that temptation, testing becomes even less effective as bugs need to be produced multiple times before they are taken seriously. Theoretical analysis, such as defining a partial order and desk checking or reviewing for correct use of the order, may also help. Another line of attack on this is to look for ways of recovering from deadlocks, such as applying database transaction concepts more widely. Patricia