Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Question whether a problem with race conditions exists in this case Date: Fri, 16 Dec 2011 08:27:49 -0800 (PST) Organization: http://groups.google.com Lines: 53 Message-ID: <25969317.245.1324052869840.JavaMail.geo-discussion-forums@prfc16> References: <8bbbbee3-adcc-4f28-aff5-2e230b047401@u6g2000vbg.googlegroups.com> Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 173.164.137.213 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1324054455 23907 127.0.0.1 (16 Dec 2011 16:54:15 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 16 Dec 2011 16:54:15 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.164.137.213; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10799 On Thursday, December 15, 2011 6:44:39 AM UTC-8, Tom Anderson wrote: > On Wed, 14 Dec 2011, Saxo wrote: >=20 > > On Dec 14, 10:26=A0pm, Eric Sosman wrote= : > > > >>> =A0 =A0private Object lock =3D new Object(); > >> > >> =A0 =A0 =A0What does `lock' buy you? =A0Why not just synchronize on th= e > >> Node itself? > > > > The purpose is only to indicate that some more fine-gtrained locking > > would be used for the real thing instead of doing a synchronized(this) > > { ... } thing. >=20 > It's quite a common pattern. I'm always a bit dubious about using an=20 > public object (FSVO 'public') as the victim of a synchronized block; how= =20 > do i know some random other bit of code in some other thread isn't going= =20 > to try to lock the object at some point, and cause trouble? You wouldn't= =20 > expose a field, would you? So why expose an object's lock? Essentially, i= =20 > see an object's lock as a feature, like a method or a field; it should=20 > only be exposed to other classes after due consideration, and if it is,= =20 > its proper use should be documented. I control that by who sees the object, e.g., a 'Collections.synchronizedLis= t()'. I see the point in what you're saying but I find it over-cautious sometimes= . It depends on whether you want the object to control its own internal locki= ng,=20 which sometimes you do, or to be part of its client's thread control, as th= e numerous standard API classes with 'synchronized' methods do. > The locking analogue of a private field is an object like the above,=20 > created for the sole purpose of supplying a lock that is provably only=20 > accessible to code which can see the private details of the class. >=20 > I have coined the name 'lockguffin' for these objects, and i encourage yo= u=20 > all to use it. When appropriate. --=20 Lew