Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder5.news.weretis.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: A question about synchronized threads Date: Sat, 30 Apr 2011 17:34:00 +0200 Lines: 43 Message-ID: <922offF2frU1@mid.individual.net> References: <3f249d87-aaf8-4732-9ee8-fd112cf82553@f31g2000pri.googlegroups.com> <8b7289b0-2b52-44f9-96a9-fe1d2661de11@k3g2000prl.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: individual.net y6tRIRcrAi/Beog3BDA/hAepZNud8zQtZ8bIT82CYSWSte0Yg= Cancel-Lock: sha1:sEY9DaB+iUCv6MlU040TwqcIDc0= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 In-Reply-To: <8b7289b0-2b52-44f9-96a9-fe1d2661de11@k3g2000prl.googlegroups.com> X-Antivirus: avast! (VPS 110430-0, 30.04.2011), Outbound message X-Antivirus-Status: Clean Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3315 On 29.04.2011 18:12, byhesed wrote: > On 4=EC=9B=9430=EC=9D=BC, =EC=98=A4=EC=A0=8412=EC=8B=9C53=EB=B6=84, Lew= wrote: >> What do you mean by "better"? What precisely is not the way you want = it? >> What is your standard of effectuality? > If too much spaces are marked as critical regions, > then the program will not be optimized. > It wastes too much time in waiting for obtaining a right to access > critical regions. > > So, in my question, better means optimization when using threads. There is no one size fits all answer to that question. It completely=20 depends on the nature of your application. For example, if read=20 accesses vastly outnumber write accesses you will get significant=20 improvements by using read write locks. If it is the other way round=20 you won't notice a big difference between using "synchronized" and a=20 read write lock (because most of the time the exclusive write lock will=20 be used). In other situations not sharing mutable state (i.e. copying mutable=20 state or using immutable state) might be the best solution. Or you use=20 a thread safe data structure such as copy on write list. There is a whole, big toolbox for writing scalable thread safe=20 applications. Eric has it exactly right with his suggestion because the = nature of the state (shared, not shared, mutable, immutable) is the=20 important aspect to reason about. I recommend reading Doug Lea's=20 excellent book on the matter. Kind regards robert --=20 remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/