I agree that you need to chose the locking mechanism that suits the needs and not necessarily based on benchmarks. I use ReentrantLock in my code because I use Conditions and tryLock(). Ultimately, it doesn't matter what lock the reactor uses because the SocketChannel uses 3 synchronized mutexes every time you call read() or write() not including the Kernel-level locks.
I grabbed the code from the ycog.com article; the code was actually broken and gave incorrect results. The reentant lock is only about 50% more transactions then synchronized in that test. For 1-2 threads on Linux, synchronized is probably the best bet. Here are the results: Random Implementor = ReentrantLock PseudoRandom Num of Player = 1 Num of call = 1745164969 Throughput = 58172 ---------------------------------- Random Implementor = ReentrantLock PseudoRandom Num of Player = 1 Num of call = 1738116961 Throughput = 57937 ---------------------------------- Random Implementor = ReentrantLock PseudoRandom Num of Player = 2 Num of call = 282705654 Throughput = 9423 ---------------------------------- Random Implementor = ReentrantLock PseudoRandom Num of Player = 4 Num of call = 1024694515 Throughput = 34156 ---------------------------------- Random Implementor = ReentrantLock PseudoRandom Num of Player = 6 Num of call = 1062739559 Throughput = 35424 ---------------------------------- Random Implementor = ReentrantLock PseudoRandom Num of Player = 8 Num of call = 1092100520 Throughput = 36403 ---------------------------------- Random Implementor = ReentrantLock PseudoRandom Num of Player = 10 Num of call = 1096784574 Throughput = 36559 ---------------------------------- Random Implementor = ReentrantLock PseudoRandom Num of Player = 12 Num of call = 1106991955 Throughput = 36899 ---------------------------------- Random Implementor = ReentrantLock PseudoRandom Num of Player = 14 Num of call = 1106136872 Throughput = 36871 ---------------------------------- Random Implementor = Synchronized PseudoRandom Num of Player = 1 Num of call = 1545588920 Throughput = 51519 ---------------------------------- Random Implementor = Synchronized PseudoRandom Num of Player = 1 Num of call = 1459511021 Throughput = 48650 ---------------------------------- Random Implementor = Synchronized PseudoRandom Num of Player = 2 Num of call = 692104828 Throughput = 23070 ---------------------------------- Random Implementor = Synchronized PseudoRandom Num of Player = 4 Num of call = 670967651 Throughput = 22365 ---------------------------------- Random Implementor = Synchronized PseudoRandom Num of Player = 6 Num of call = 674735400 Throughput = 22491 ---------------------------------- Random Implementor = Synchronized PseudoRandom Num of Player = 8 Num of call = 659368939 Throughput = 21978 ---------------------------------- Random Implementor = Synchronized PseudoRandom Num of Player = 10 Num of call = 665119697 Throughput = 22170 ---------------------------------- Random Implementor = Synchronized PseudoRandom Num of Player = 12 Num of call = 681904479 Throughput = 22730 ---------------------------------- Random Implementor = Synchronized PseudoRandom Num of Player = 14 Num of call = 665189487 Throughput = 22172 ---------------------------------- On Tue, Sep 19, 2017 at 12:42 PM, Emmanuel Lécharny <elecha...@gmail.com> wrote: > 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 > >
