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 <elecha...@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 <elecha...@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 > >
