Re: [Jmri-developers] AbstractMRTrafficController handleOneIncomingReply() & Programming

[Bob J. <rg...@pa...>]

On Apr 16, 2012, at 3:13 AM, Kevin Dickerson wrote:

> On 16 April 2012 06:16, Paul Bender <pau...@ac...> wrote:
>> 
>> Right, I am not talking about the swing thread, but the relationship between the transmit thread and the receive thread.
>> 
>> When a reply is received by the receive thread, the transmit thread is notified, and it sends out a) the last message ( again ) if the reply was a recoverable error, or b) a new message if the last reply was not an error response.
>>> 
>> 
>> If we use invokeLater in the receive thread, the transmit thread may be notified, and continue with the next message, before the swing thread passes the data on to all the listeners.
>> 
>> On some systems, there are messages that we receive with or without a request.  The traffic controller has no way to know if the message was requested or not until the listeners see the message.  On XPressNet systems, this happens with feedback messages for turnouts and sensors.  I believe this can happen with AIU messages on NCE systems.  ( and I am currently working on adding support for XBee modules, which can act similarly )
>> 
>> Paul
> 
> The previous time that I mentioned it was in the following thread,
> 
> https://sourceforge.net/mailarchive/message.php?msg_id=28857758
> 
> When the swing thread is in use the reply message get stuck at the
> invokeandwait and blocks the rcvThread, it then gets timed out and the
> transmit queue sends the next message(s). The message stuck by the
> invokeandwait eventually gets released when the swing thread becomes
> free and the message gets sent out after a notification has been sent
> that it had timed out.
> 
> I did notice that opening a roster entry for programming does have an
> affect on the processing of message replies.
> 
> Ignoring this issue initially maybe my question should of been, why
> would performing a "Read All Sheet", cause the swing thread to be in
> continuous use.


The prior thread was about how things propagate within JMRI on the Swing thread. 

Here, we're making the distinction between doing that with invokeAndWait and invokeLater.  I don't understand Paul's point, because I think that Swing's rigorous ordering should allow invokeLater to work fine, which will in turn allow the transmit/receive process to continue while Swing is working (That's why transmit and receive have their own threads, after all)

Many of the systems already use invokeLater in their handleOneIncomingReply() methods for queuing the notifications onto the Swing thread.  

The parent handleOneIncomingReply() in AbstractMRTrafficController does use invokeAndWait. It was changed from invokeLater in CVS revision 1.9 in 2003 (!!).  The comment on that is "Change order of xmt and reply handling to avoid race condition". I don't remember anything more than that, unfortunately. The changes are more than just the invoke* method:

http://jmri.cvs.sourceforge.net/viewvc/jmri/jmri/jmrix/AbstractMRTrafficController.java?r1=1.8&r2=1.9

Not sure how to proceed.  Changing this might break things, but I think that's because they're already broken (in terms of synchronization) and this is just making it less visible.

Bob
--
Bob Jacobsen
rg...@pa... +1-510-486-7355 AIM, Skype JacobsenRG