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
