Re: MINA3.0 recommended

[Jonathan Valliere]

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

Re: MINA3.0 recommended

[Emmanuel Lécharny]

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

Re: MINA3.0 recommended

[Emmanuel Lécharny]

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.

It does. MINA use always the same IoProcessor for one session, to avoid
having to manage the session attributes access across may threads. As
you said, one can add a Executor filter, but then, it's up to the
application to deal with concuttent accesses.

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

I find this article a bit dubious. The numbe this guy get for 2 threads
is clearly problematic. You will find other blogs that shows Locks are
better as soon as you have more than a thread :

http://lycog.com/concurency/performance-reentrantlock-synchronized/
or
https://objectpartners.com/2011/11/29/java-synchronization-method-performance-comparison/

I won't say I fully trust those blog posts : there are too many moving
pieces (Java version, benchmark, OS used, etc)

But overall, I would say it's not a clear cut.


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: MINA3.0 recommended

[Jonathan Valliere]

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

Re: MINA3.0 recommended

[Emmanuel Lécharny]

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

Re: MINA3.0 recommended

[Jonathan Valliere]

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

Re: MINA3.0 recommended

[Emmanuel Lécharny]

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

Re: MINA3.0 recommended

[Emmanuel Lécharny]

Le 18/08/2017 à 07:53, 胡阳 a écrit :
> Hi guys:

Hi ! (Sorry, I can't use your first name, my keyboard is a bit limited ;-)

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

Probably :-) This is just an effort to improve from MINA 2, and we are
very open to any proposal !
> 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.
You are looking at an old version of the code base. The current (not
released) version is using a ConcurrentLinkedQueue, which does not
require a synchronized anymore.

> 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.
And we don't disagree :-)

If you are interested in this code, feel free to dig the trunk, which
contains the latest changes. Note that it's not a very active project
atm, but we would really appreciate any contribution !

You can also use github to push PR, would you feel like contributing :
https://github.com/apache/mina

Thanks !

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org