commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?
Date Wed, 28 May 2014 12:12:48 GMT
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 <rmannibucau@gmail.com>:

>
> 2014-05-27 21:13 GMT+02:00 Thomas Vandahl <tv@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message