Path: csiph.com!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: multithreaded cache? Date: Fri, 18 May 2012 23:45:30 +0200 Lines: 27 Message-ID: References: <4fb69812$0$6849$e4fe514c@news2.news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net ZegqoWRUy65ipLyAKyWweQI5Viw2WyqYEqmrTLP8tQp/tnOZx66nnGXfHL4JVrWDM= Cancel-Lock: sha1:geM746sipNYUaDEKFtADBr+AOBc= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: <4fb69812$0$6849$e4fe514c@news2.news.xs4all.nl> Xref: csiph.com comp.lang.java.programmer:14633 On 18.05.2012 20:42, Silvio Bierman wrote: > On 05/17/2012 11:54 AM, Robert Klemme wrote: >> I provide a variant of Silvio's, Eric's and Daniel's solution which >> should yield higher throughput because it works without read write >> locking. You can find it as gist in case the code is garbled in the >> newsgroup posting: >> https://gist.github.com/2717818 > I think you have as many locks as I suggested (being one)? My initial > implementations of something like this used a plain map with an extra > lock but later cases used the by then available ConcurrentHashMap as > well, making one lock redundant. You didn't show it here, did you? I can's seem to find it in the thread. Note that CHM does also do synchronization. I am not sure from your statement what exact locking scheme you apply. There does seem to be one difference though: I my version the second lock goes away after the value has been computed so there is only the sync of CHM left. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/