the point is putIfAbsent is costly but globally once (can be done concurrently but this is ignorable at runtime). Only important thing is to ensure then the system uses a single instance.
Issue with sychronized is that it doesn't scale. If you go upper to 10 threads you are slow. The other point shocking me a bit is you need everything needs to be processed sequentially. For a cache you globally want the last value. So then you slow down the process cause you were not preempted. I globally get the idea and we could use a LockFactory + ReentrantLock to replace synchronized (would already be faster), this way we could even get a NoLockFactory ;). wdyt? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-26 21:33 GMT+02:00 Thomas Vandahl <t...@apache.org>: > On 25.05.14 17:45, Phil Steitz wrote: > > On 5/25/14, 8:18 AM, Romain Manni-Bucau wrote: > >>> And please consider reacting to Phils comment on the removal of > >>> synchronized keywords. It took years to pinpoint the race issues in the > >>> JCS code. I don't claim the current situation to be perfect but at > least > >>> it does not cause data corruption. I want to go forward, not backward. > > > > On this topic, one thing that would probably be helpful would be if > > someone familiar with the code could comment a little or post > > references to past bugs that show what race conditions / data > > invariants we have to worry about. If there is a locking strategy > > implicit in the pre-CHM code, it would be great to make that > > explicit so Romain can know what he has to worry about beyond just > > maintaining integrity of the backing store (which CHM can do). > > JCS implements a composite cache, that is, a cache with a memory cache > with different eviction algorithms (you may call it level one) and zero > or more "auxiliaries" that handle the second level of caching: disks, > databases, distributed caches etc. > > We have two issues with synchronization here. One is more or less some > kind of a transaction issue that means that data operations on the *same > cache key* should be performed in sequence and completed through the > chain of auxiliaries. That's why CompositeCache is synchronized. See > JCS-73. I tried several approaches to get rid of this synchronization > but everything I came up with was slower than the synced code. > > The other issue is the handling of common data structures within the > cache implementations. For example putting a value into the LRU memory > cache requires not only putting it into the map but updating the linked > list that keeps track on the LRU element. So having a CHM doesn't help > much here. > > The same is true for most of the auxiliaries where several data > structures have to be kept consistent. The only exception are the two > disk caches where I managed to get the synchronization out of the code > with the help of NIO. See JCS-69, JCS-76, JCS-82, JCS-92 to name just a > few. > > In addition, JCS employs several background threads to queue operations > and to do eviction. If you want to see the effect of unsynchronized > access, have a look at the cache statistics. In continuous operation, > the numbers are plain nonsense. > > That said: Quite a few of Romains replacements with CHM are maps that > keep track of certain auxiliary caches of the same type within their > managers. They employ the simple pattern > > cache = map.get(cacheName); > if (cache == null) > { > // create cache instance, open databases, start servers, create files > etc etc. > } > > So if you want to avoid to run these expensive operations, you don't > want to create a cache instance on spec just for putIfAbsent() and you > need synchronization again. That is at least my level of knowledge. > (I don't like this construct of multiple managers and factories, I > consider it over-engineered but it is not high on my list) > > Hope I could shed some light on this. > Bye, Thomas. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
