Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!feeder.news-service.com!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'bug': 0.02; 'context': 0.04; 'cleanup': 0.07; 'received:edu.au': 0.07; 'locks': 0.09; 'exception': 0.12; 'backwards.': 0.16; 'debugged': 0.16; 'from:addr:cs': 0.16; 'from:addr:zip.com.au': 0.16; 'from:name:cameron simpson': 0.16; 'function)': 0.16; 'message- id:@cskk.homeip.net': 0.16; 'monitors': 0.16; 'occurs,': 0.16; 'received:202.125.174': 0.16; 'received:202.125.174.133': 0.16; 'received:boardofstudies.nsw.edu.au': 0.16; 'received:cskk.homeip.net': 0.16; 'received:harvey.boardofstudies.nsw.edu.au': 0.16; 'received:homeip.net': 0.16; 'received:nsw.edu.au': 0.16; 'cc:addr :python-list': 0.16; 'wrote:': 0.16; 'cheers,': 0.18; 'have:': 0.18; 'cc:no real name:2**0': 0.20; 'seems': 0.20; 'cc:2**0': 0.22; 'header:In-Reply-To:1': 0.22; 'versions': 0.23; 'base.': 0.23; 'locking': 0.23; 'code': 0.25; 'creating': 0.25; 'code.': 0.26; "i'm": 0.27; 'fact': 0.27; 'cc:addr:python.org': 0.30; 'decorators': 0.30; 'lock': 0.30; 'reviewing': 0.30; 'use?': 0.30; 'equivalent': 0.31; 'too': 0.33; 'there': 0.33; '...': 0.34; 'header:User-Agent:1': 0.34; 'things': 0.34; '(for': 0.35; 'charset:us-ascii': 0.36; 'received:au': 0.36; 'doing': 0.36; 'thread': 0.37; 'easier': 0.38; 'subject:: ': 0.39; "it's": 0.40; 'more': 0.60; 'managers': 0.62; 'wide': 0.63; 'received:202': 0.66; 'making': 0.67; 'cameron': 0.67; 'safe': 0.69; 'money.': 0.72; 'wheel': 0.84; 'here!': 0.91; 'prone': 0.91; 'technique': 0.93 Date: Tue, 16 Aug 2011 09:37:21 +1000 From: Cameron Simpson To: python@bdurham.com Subject: Re: Reusable ways to wrapping thread locking techniques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1313430966.16911.140258129884193@webmail.messagingengine.com> User-Agent: Mutt/1.5.21 (2010-09-15) References: <1313430966.16911.140258129884193@webmail.messagingengine.com> Cc: python-list@python.org X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 38 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1313451867 news.xs4all.nl 23943 [2001:888:2000:d::a6]:37998 X-Complaints-To: abuse@xs4all.nl Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:11481 On 15Aug2011 13:56, python@bdurham.com wrote: | I'm reviewing a lot of code that has thread acquire and release | locks scattered throughout the code base. | | Would a better technique be to use contextmanagers (for safe | granular locking within a function) or decorators (function wide | locks) to manage locks or am I making things too complicated? No, you're on the money. | Am I reinventing the wheel by creating my own versions of above | or are there off-the-shelf, debugged versions of above that one | can use? I routinely have: some_lock = allocate_lock() ... with some_lock: code here! Doing the equivalent with decorators to make monitors seems perfectly reasonable to me too. Do it all with context managers if you can; they do reliable lock release even when an exception occurs, and don't clutter the code with distracting and hard to verify cleanup code. It's worth it just to make everything more readable. The fact that it makes the code smaller and easier to maintain and less bug prone is just sugar. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ My mind is like a blotter: Soaks it up, gets it backwards.