I would add Brian Goetz take on synchronized vs Lock :
https://www.ibm.com/developerworks/library/j-jtp10264/ Le 19/09/2017 à 15:28, Jonathan Valliere a écrit : > 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 >> >> -- Emmanuel Lecharny Symas.com directory.apache.org
