Anfang der weitergeleiteten Nachricht:
> Von: "Michael Haberler" <[email protected]> > Betreff: [emc:bugs] #328 Problem using AXIS together with HALUI > Datum: 01. August 2013 18:45:03 MESZ > An: "[emc:bugs] " <[email protected]> > Antwort an: "[emc:bugs] " <[email protected]> > > Hi Sascha, > > the more I think of it the lost ack problem you describe is the harder of the > two issues. > > I am not sure this is actually possible to do with responses going through an > 'NML buffer' (pretty much a shared memory region), Also, I would like to > solve the problem without assuming shared memory between producers, which may > or may not be the case, but turn out rather restrictive eventually. > > A clean solution not requiring a globally unique id would be: > > a command queue > a response queue > both commands and reponses are tagged by a tuple(local serial (need not be > unique),producer identifier (needs to be unique)). A producer peeks on the > response queue until his producer id comes up, then reads. > Would you agree this solves the problem in principle? I'm not suggesting at > this point it actually be done this way, I am interested in a clean design. > > If that is the case, the next question is: can we coordinate consumers of > acks in such a way that a response is not read by any other than the > legitimate originator? I think it is, producers just peek until 'their' > producer id comes up, then read. > > This would shift the issue to ack production, the consumer: an ack cannot be > written to the buffer unless the legitimate producer who caused the previous > ack has read 'his' last ack. The write_if_read() method might be the tool for > that. > > How do you see this option? In terms of throughput the dual-queue solution is > better because there would be no lock-step between ack production and > consumption, but I am not sure it matters much. Also, EMC_STAT is a sizable > structure and updated a lot, so this might have some performance impact as > now several EMC_STAT copies would be in-flight in the response queue. > > -- > > re test case: I hope a volunteer comes up, it would be great to have an > independent pair of eyeballs on the issue. It's a very interesting issue, but > I'm a bit pressed for time to do that right away. Since it is such a > fundamental problem, and very few folks really understand the somewhat > convoluted semantics of NML, it would be relevant not just as a test case but > as a tutorial ;) > > -- > > in a zmq scenario, this would be rather simple to solve: acks are pushed into > a PUBLISH channel (including originator id), and any producer interested in > acks subscribes to that channel. The semantics of the PUBLISH operation > guarantees that no acks are lost. > > Michael > [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 03:58 PM 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
