You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@mina.apache.org by Julien Vermillard <jv...@gmail.com> on 2013/05/11 19:32:20 UTC

DefaultAttributeContainer locks ?

Hi,
DefaultAttributeContainer.java (which is the container session
attributes) use a hash map + some read and write lock.

I wonder why we don't simply use a ConcurrentHashMap here ?

Julien

Re: DefaultAttributeContainer locks ?

Posted by Emmanuel Lécharny <el...@gmail.com>.

Le 5/11/13 8:54 PM, Julien Vermillard a écrit :
> i made a (very) dumb micro bench, if you access the structure from
> always the same thread : so it never lock the ConcurentHashMap version
> is quite faster :
>
> https://gist.github.com/jvermillard/5560969
>
> for accessing 1000000000 entries :
> time : 22396 ms for hash map + read/write lock
> time : 8034 ms for concurrent hash map

I would notbet too much on those results ;-)...

But I think it's a better idea to use a ConcurrentHashMap
OTOH, be sure to use the appropriate concurrencyLevel (default is 16,
which is way too high in most of the case). I would initialize the
ConcurrentHashMap with a concurrencyLevel equal to the number of threads
used to process the incoming data.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: DefaultAttributeContainer locks ?

Posted by Julien Vermillard <jv...@gmail.com>.

i made a (very) dumb micro bench, if you access the structure from
always the same thread : so it never lock the ConcurentHashMap version
is quite faster :

https://gist.github.com/jvermillard/5560969

for accessing 1000000000 entries :
time : 22396 ms for hash map + read/write lock
time : 8034 ms for concurrent hash map

Julien

On Sat, May 11, 2013 at 7:32 PM, Julien Vermillard
<jv...@gmail.com> wrote:
> Hi,
> DefaultAttributeContainer.java (which is the container session
> attributes) use a hash map + some read and write lock.
>
> I wonder why we don't simply use a ConcurrentHashMap here ?
>
> Julien