mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: MINA3.0 recommended
Date Tue, 19 Sep 2017 16:42:39 GMT
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
View raw message