Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!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, 25 May 2012 17:36:08 +0200 Lines: 43 Message-ID: References: <4fbf252e$0$87578$742ec2ed@news.sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net B3aD6P/cYD+wYJWTfzlWqwz5RNNGFFVtTfoHU8nvAedChT2h2deV0zLWVboxLwRrY= Cancel-Lock: sha1:KcIVpZkVsaRTHgtxHvAYu04ALwo= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: <4fbf252e$0$87578$742ec2ed@news.sonic.net> Xref: csiph.com comp.lang.java.programmer:14793 On 25.05.2012 08:22, Kevin McMurtrie wrote: > Ha, this is an interview question that I use. > > What you need is row level locking for the cache load. But not all the time. See https://gist.github.com/2717818 > Step 1) > Use synchronized operations to map your key to a value; creating an > uninitialized value in the map if needed. Use whatever tech you want. > A synchronized block on a HashMap is simplest and performs the fastest > on 1 or 2 core systems. A ConcurrentHashMap sometimes performs better > with 4+ core systems. In my experience a CHM performs better even on a 1 or 2 core system. > Step 2) > Synchronize on the value. Initialize it if needed. > > > Step 1 blocks all cache access for only for a very short moment to make > sure that a key always has a value. Step 2 blocks access independently > for each cache value to make sure that it is loaded. It will perform > well for continuous use by several CPU cores. Google has some high > concurrency Maps that aren't too bad either. Actually once the value is in the cache you do not need any step 2 synchronization any more. > In the 16 core range you'll find that any kind of exclusive lock causes > stalls where threads suspend while holding locks, causing a backlog that > reinforces itself. A concurrency expert can fix that using complex > Compare-And-Swap designs. Basically this is what CHM does with putIfAbsent() internally. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/