Trustin,
I think there is theoretically still a chance that two threads
synchronize on different lock object for the same session:
+ private Object getDecoderLock( IoSession session )
+ {
+ Object lock = session.getAttribute( DECODER_LOCK );
+ if( lock == null )
+ {
+ lock = new Object();
+ session.setAttribute( DECODER_LOCK, lock );
+ }
+
+ return lock;
+ }
thread A calls session.getAttribute( DECODER_LOCK ) and gets null
thread B calls session.getAttribute( DECODER_LOCK ) and gets null
thread A creates a new lock object lockA and stores it in the session
thread B creates a new lock object lockB and stores it in the session
thread A locks on lockA and enters decoder.decode
thread B locks on lockB and also enters decoder.decode
I guess you can't get around locking on the IoSession instance itself ?
Maarten
On 3/28/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
Steven,
Have a look at the diff that Trustin posted: http://tinyurl.com/2ar8ky
ProtocolCodecFilter stores a lock object in the session and locks on it before
calling
decoder.decode()
As I see it, this means that no two threads can call decoder.decode for the
same session simultaneously.
Maarten
On 3/28/07, Steven E. Harris <[EMAIL PROTECTED]> wrote:
> Trustin Lee < [EMAIL PROTECTED]> writes:
>
> > By doing this, all decoders will be free from the visibility
> > problem.
>
> I missed the earlier part of this discussion. Does this mean that
> ProtocolDecoder.decode() calls will be synchronized to a particular
> decoder? That is, a given decoder instance will only be called on by
> one thread at a time?
>
> I thought we had discussed this earlier and confirmed that it was
> intentional that a decoder could be called on from multiple threads
> simultaneously.
>
> --
> Steven E. Harris
>
