mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Valliere <jon.valli...@emoten.com>
Subject Re: MINA3.0 recommended
Date Tue, 19 Sep 2017 17:00:50 GMT
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 <elecharny@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 <elecharny@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 <
> elecharny@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message