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 Mon, 18 Sep 2017 22:24:44 GMT
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.

On Mon, Sep 18, 2017 at 5:35 PM, Emmanuel Lécharny <elecharny@gmail.com>

> 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

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