Found an IBM article showing globally what I experimented: http://www.ibm.com/developerworks/java/library/j-jtp10264/
So I'll first add ReentrantLock where synchronized was used, then bench it again and see depending performances if we need the LockFactory abstraction or not. Does it work for you? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-28 13:52 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > > 2014-05-27 21:13 GMT+02:00 Thomas Vandahl <t...@apache.org>: > > On 26.05.14 22:05, Romain Manni-Bucau wrote: >> > 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. >> >> Right, but what if the instance creates a file, socket or similar? If we >> want to do this we need to postpone all costly initialization into an >> initialize() method. In any case, I think this could simplified a lot by >> removing all separate managers. >> >> > well in this case locking should be where it is needed (around socket init > for instance). Idea I got was to say "avoid to force something you don't > want". Said otherwise don't put constraints before really needing it. Then > JCS is extensible so the question is where should be constraints? Can't > really be in the API IMHO since then impl can maybe be too constrainted. > > >> > 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'm open to suggestions on how to solve this. Feel free to experiment >> with JCSConcurrentCacheAccessUnitTest to see the effects. A put *must* >> be finished before the cached object can be accessed. >> >> > Hmm, I'm not 100% convinced of it actually. Sequentially that's true but > with multiple threads if that's not true that's not a big deal. Thanks for > the pointer on JCSConcurrentCacheAccessUnitTest, I'll check it. > > >> > 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 ;). >> >> I like the idea. It's certainly worth a try. My tests with locks did not >> show much improvement, though. >> >> > Ok I take this task. What I saw from my experiments was that with > 10 > threads locks were better than synchronized but maybe JCS has something > making it wrong. I'll check it! > > >> Bye, Thomas. >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >
