mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Fisk"...@lastbamboo.org>
Subject Re: Tutorial on ProtocolCodecFilter, state and threads
Date Fri, 13 Jul 2007 01:20:09 GMT
Anyone else have thoughts on this issue?  It still seems like a key part of
understanding MINA, and I do think the Maarten's overall excellent and very
helpful tutorial is misleading as it stands on this point.

-Adam


On 6/23/07, Maarten Bosteels <mbosteels.dns@gmail.com> wrote:
>
> On 6/23/07, Adam Fisk <a@lastbamboo.org> wrote:
> >
> > Hi Maarten-
> >
> > Thanks for the link to that discussion thread.  It seems like there's
> > quite
> > a bit of confusion on this point, though.  The thread really didn't
> reach
> > a
> > common consensus in my reading of it.
> >
> >
> > > Indeed, I want thread-2 to see the changes made by thread-1.
> > > But without synchronization, there is no such guarantee.
> >
> >
> > Right, but the tutorial snippet says "MINA ensures that there will never
> > be
> > more than one thread simultaneously executing the decode() function for
> > the
> > same IoSession".  For that to be true, there's gotta be some
> > synchronization
> > somewhere.  I decided to dig into the code a little bit for the
> > 1.1.0branch, and indeed ProtocolCodecFilter has the following:
> >
> >         try
> >         {
> >             synchronized( decoderLock )
> >             {
> >                 decoder.decode( session, in, decoderOut );
> >             }
> >         }
> >
> > With the code above, the changes made by thread-1 on the decoder *are
> > guaranteed to be seen by thread-2*.
>
>
> Indeed.
>
>   Now, I realize this is an
> > implementation detail of 1.1.0, but the tutorial description above seems
> > to
> > be relying on that detail.
>
>
> The fact that "no two threads will execute decode() for the same
> IoSession"
> is not an implementation detail, it's a guarantee of the framework.
>
> The use of syncronized(decoderLock) is an implementation detail, but I
> can't
> immediately find
> an alternative implementation that would cause visibility problems in your
> decoder but still
> guarantee that "no two threads will execute decode() for the same
> IoSession"
>
> so maybe that paragraph in the tutorial is not totally accurate.
> Mina experts, what do you think about it ?
>
> Still, I think it's worth reminding people about the danger of the
> visibility problem in general.
>
> So it seems like it should be totally fine to
> > have a ProtocolCodecFactory that returns a new decoder on each
> getDecoder
> > call (effectively one decoder per session).  I still don't see the
> > disadvantage of doing this.
>
>
> I guess you're right.
> But the difference between one decoder per session or one decoderState per
> session is small in my eyes.
>
> It certainly seems less complicated that way!
> >
> > Thanks again for your patience Maarten.  Seems like a key point we
> should
> > all be clear on, so that's why I'm trying to dig a little deeper here.
>
>
> Right. Let's see what the rest thinks about it.
>
> Maarten
>
> -Adam
> >
>

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