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 <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 > >
