Anfang der weitergeleiteten Nachricht:
> Von: "Sascha Ittner" <[email protected]> > Betreff: [emc:bugs] #328 Problem using AXIS together with HALUI > Datum: 01. August 2013 17:58:24 MESZ > An: "[emc:bugs] " <[email protected]> > Antwort an: "[emc:bugs] " <[email protected]> > > Hi Michael, > > yes, the scenario you describe is correcet. But there is an other one: > > task A writes a command+local serial into the command buffer > the command consumer is processing and acknowledging the command > task B goes ahead and also writes a command to the buffer with its own serial > B's command gets executed and 'acknowledged' > task B reads the ack (local_serial_number = echo_serial_number) and is happy > task A (which is delayed for some reason) will wait until timeout for it's > local_serial_number = echo_serial_number > That is the reason I've choosen a global serial number. In this case A+B can > wait for a echo_serial_number >= local_serial_number (with respect to > datatype overflow). But this is also a compromise since you can only get the > error state of the last command. > > In summary we have two problems: > - overwriting of commands in the command buffer > - waiting for the ack > > The correct solution would be some kind of (logical) bidirectional 1:n > connection (like a TCP connection for example). You can send a command and > just the sender get it's acknowledgement. Global state information like > current position could be still reside in a global buffer or a current copy > could be requestet by a special command via the connection. > > I've tried to create a minimal invasive patch for the issue, so I hadn't to > chage the existing concept too much. The intention was to fix the current > version, not to create a new approach (which might be needed). Most of the > code changes are dedicated to clean up the command send code. There where so > many serialNumber++ and so on that I've decided to clean them up and > implement the logic in single functions. > > If you keep the buffer instead of the queue and implement some kind of > locking (could be done with write_if_read I think) then you also need to > implement some kind of retry logic. Implementing a queue on the other hand > just requires a configuration change and replacing the peek() with a read(). > > Zmq and protobuf seems to be pretty cool components to implement a clean > solution. I don't known them (yet) in depth, but what I've seen on the > internet looks very promising. Zmq can build a lot of different communication > relationships. > > How could we proceed with the test case? > > regards > Sascha > > [bugs:#328] Problem using AXIS together with HALUI > > Status: open > Created: Wed Jul 31, 2013 10:19 PM UTC by Sascha Ittner > Last Updated: Thu Aug 01, 2013 06:54 AM UTC > Owner: nobody > > I've found a problem in using AXIS together with HALUI, but it seems a > general problem when two or more user interfaces are used the same time. > > If I use HALUI excessively I've found that axis is blocked some times. Even > more problematic for me is the fact that in some cases the HALUI action get > lost. After investigating the involved code I've found the reason. I'll try > to describe my thoughts: > > The communication between UI and EMCTASK is done by shared mem buffers (cmd + > status). If a command is issued, the command object is copied to the cmd > buffer (including a command serial number). Then the sender (the UI) waits > for the reception and optionaly for the completion of the command. The wait > is relized by waiting for the appearance of the issued serial number in > echo_serial_number of the status buffer. The serial number generator is local > to the ui process and no sync methods (except from a semaphore on the buffer > read/write functions) is involved. This causes two problems: > > the first issued command (by AXIS for example) can get overwritten by the > second one (e.g. HALUI) before EMCTASK has processed it > even if both commands are processed correctly, one of the wait functions will > time out because the serial number does not match. > As I needed a quick (hopefully not (so) dirty) fix I've created a patch that > allows to generate the serial number in an atomic way on the cms write and > also configures emcCommand as a queue instead of a buffer. > > I will enjoy your feedback > > Sascha > > Sent from sourceforge.net because you indicated interest in > https://sourceforge.net/p/emc/bugs/328/ > > To unsubscribe from further messages, please visit > https://sourceforge.net/auth/subscriptions/ > ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
