mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Valliere <jon.valli...@emoten.com>
Subject Re: MINA3.0 recommended
Date Tue, 19 Sep 2017 13:28:50 GMT
I forget, does MINA uses the same Processor for both read and write
operations?  If so, there will never be contention unless you use a Thread
Executor Pool in the Filters.

If you look at the tests here:
https://dzone.com/articles/synchronized-vs-lock  You can see that until you
really hit > 2 threads, sync actually is faster.

Personally, I use a custom ReentantLock but my use-case is much more
complicated.

On Tue, Sep 19, 2017 at 1:31 AM, Emmanuel Lécharny <elecharny@gmail.com>
wrote:

>
>
> Le 19/09/2017 à 00:24, Jonathan Valliere a écrit :
> > Synchronization, unlike Locks, does not create any memory garbage and are
> > just as fast as CAS under low locking activity.  Just because CAS/ Locks
> > are faster when 8 threads are accessing one object, doesn't mean that
> > standard Mutex Synchronization doesn't work just find when almost all of
> > the time a single thread acquires the lock.  In reactor IO frameworks,
> > there is almost never more than one thread accessing the resource.  Full
> > Locks are usually overkill unless there is something specific you want to
> > attempt.  NIO internally uses the synchronized keyword for all state and
> > read / write locking anyway.
>
> FTR, the number of threads MINA uses by default is pretty limited : nb
> Cores +1. The main place where yo ight have contention is when responses
> are enqueued, because a session might be active on more than one thread
> (like, for LDAP, you might have a Search request *and* an Abandon
> Request executed in parallel).
>
> IMHO, such a situation should be quite rare, as you said, and it would
> worth it analyse the pros and cons of each solution, my point being that
> we simply discarded using alternative synchronisation mechanisms years
> ago (but that was back when Java 5 was out, when we were stuck on Java
> 4). We haven't revisited the item since them, or barely.
>
> What I mean is that the code base is pretty old and we should, at some
> point, check if any other solution wouldn't be better all things being
> equal. And if synchronized sections are proven o be more efficient in
> the general case, there is no reason to ditch it, of course !
>
>
> Thanks for your valuable input !
> >
> > On Mon, Sep 18, 2017 at 5:35 PM, Emmanuel Lécharny <elecharny@gmail.com>
> > wrote:
> >
> >>
> >> Le 18/08/2017 à 07:53, 胡阳 a écrit :
> >>> Hi guys:
> >>> I read the source code of MINA3.0M2. The style of the code is very
> good,
> >> the structure is clear, the design is concise and efficient, especially
> the
> >> use of Selector is unexpected. However, the enqueueWriteRequest method
> and
> >> the processWrite method in the AbstractNioSession are somewhat flawed.
> >>> I see the source code in the enqueueWriteRequest method was originally
> >> "synchronized (writeQueue)", but was commented out, personal speculation
> >> may be the author feel that this treatment will affect performance.
> >>> My approach is to use CAS to ensure memory visibility and atomic, see I
> >> see the startSync, finishSync method, feeling that this may be more
> secure
> >> after some of the performance will not lose too much.
> >>> A little personal humble opinion.
> >> Sorry for coming back so late... Busy days :/
> >>
> >> I do agree that we should use CAS whenever we can, and Thread Local
> >> Storage, instead of any other synchronisation solution.
> >>
> >> Feel free to propose patches that we could inject into teh code !
> >>
> >> --
> >> Emmanuel Lecharny
> >>
> >> Symas.com
> >> directory.apache.org
> >>
> >>
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>

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