On 3/28/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
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 ?
private Object getDecoderLock( IoSession session )
{
synchronized (session}
{
Object lock = session.getAttribute( DECODER_LOCK );
if( lock == null )
{
lock = new Object();
session.setAttribute( DECODER_LOCK, lock );
}
return lock;
}
}
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
> >
>
>
