On 6/22/07, Adam Fisk <[EMAIL PROTECTED]> wrote:
Thanks for getting back to me Maarten. Responses inline. > It's not because thread-1 has finished its decode call before thread-2 > starts handling more data, > that thread-2- will "see" the changes to the decoderState made by > thread-1. > This is a consequence of The Java Memory Model (do a google search on > this, > or try http://g.oswego.edu/dl/cpj/jmm.html) Hmnn...I'm still not clear on this. Don't you want thread 2 to see changes made by thread 1?
Indeed, I want thread-2 to see the changes made by thread-1. But without synchronization, there is no such guarantee. The two threads must use some synchronization mechanism, to ensure that they see each others changes. It might seem strange at first, but 'the smart guys' who designed tha Java Memory Model claim there are good reasons for this. For one thing, it enables the compiler and the JRE to do some optimizations (statement reordering and such). Again, I am not an expert on concurrency, but I can highly recommand http://jcip.net/ If thread 1 successfully sets the state in the decoder
for an IoSession, and then thread 2 comes along with more data, you want thread 2 to use the state thread 1 set, right? If both thread-1 and thread 2 can be executing decode() simultaneously, it's a totally different story (and Doug Lea's concurrency nuances come into play), but your tutorial claims this is not the case. > I thought so too, until people on this mailing list told me about the > disadvantages of that approach. Interesting. Were those private messages or messages on the list? I'll have to do a little digging if they were on here.
see http://www.nabble.com/ProtocolDecoderAdapter-and-session-state.-tf3413638.html#a9542168 Maarten
