Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 97478 invoked from network); 10 Feb 2005 13:21:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 10 Feb 2005 13:21:00 -0000 Received: (qmail 87540 invoked by uid 500); 10 Feb 2005 13:20:58 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 87502 invoked by uid 500); 10 Feb 2005 13:20:58 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 87487 invoked by uid 99); 10 Feb 2005 13:20:58 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from mail.elsag.de (HELO gateway.elsag.de) (134.98.65.18) by apache.org (qpsmtpd/0.28) with SMTP; Thu, 10 Feb 2005 05:20:57 -0800 Received: from vwall.elsag.de by gateway.elsag.de via smtpd (for hermes.apache.org [209.237.227.199]) with ESMTP; Thu, 10 Feb 2005 14:20:55 +0100 Received: from esmail by esmail via smtpd (for vwall.elsag.de [192.168.100.108]) with ESMTP; Thu, 10 Feb 2005 14:20:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: concurrency and starting a synchronized block Date: Thu, 10 Feb 2005 14:20:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: concurrency and starting a synchronized block Thread-Index: AcUPcSCg7hrc35M6TLipfOAxtBCJnAAAfOhA From: =?iso-8859-1?Q?J=F6rg_Schaible?= To: "Jakarta Commons Developers List" X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Torsten Curdt wrote on Thursday, February 10, 2005 2:07 PM: > Guys, forgive me if this too off topic... >=20 > ...but I thought it is somehow related to > collections that's why I am bringing it up > here anyway. I bet someone of you will know.... >=20 > Consider this code... >=20 > Object o =3D map.get(key); > if (o =3D=3D null) { > synchronized(map) { > map.put(key,new Object()); > } > } >=20 > 99% of the time the "get"s on the map are going > to return an object. That's why I would like > to avoid synchronizing the "get" access. > Now since a "put" might corrupt the data it > has to be synchronized. then get() twice: Object o =3D map.get(key); if (o =3D=3D null) { synchronized(map) { o =3D map.get(key); if (o =3D=3D null) { map.put(key,new Object()); } } } since 99% of the time it will not enter the block, the second lookup = does not matter ... Regards, J=F6rg --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org