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 > >
