You guys are making it so complicated. Why not just have each copy of the process do this;
S ^RRCTST($H,$J)=$G(^RRCTST($H,$J))+1 Then you can run as many copies of the routine as you wish for as long as you wish and in post processing see the order of the execution. If this granularity is too coarse, make a call to the OS to get the current millisecond count and replace the $H reference. ----- Original Message ----- From: "Gary Monger" <[EMAIL PROTECTED]> To: <hardhats-members@lists.sourceforge.net> Sent: Tuesday, January 17, 2006 8:15 PM Subject: RE: [Hardhats-members] Interleaving > For that kind of precision, I would think any device would introduce too > much overhead. > > You could have each job write to a location in memory with VIEW. It would > write its name and the iteration. Both jobs write to the same location, a > third process reads from the location with $VIEW. The third job needs to > run at a higher priority. > > You could probably even view into a device buffer. > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Gregory > Woodhouse > Sent: Tuesday, January 17, 2006 10:42 PM > To: hardhats-members@lists.sourceforge.net > Subject: Re: [Hardhats-members] Interleaving > > > On Jan 17, 2006, at 7:07 PM, Gary Monger wrote: > > > Wouldn't the HL7 link monitor be an example of this? The background > > processes write something about their state to a global and some other > > process monitors the global and displays it. > > I don't think so. The time scales are very different: The HL7 package > only processes a few messages per second, but as our tests have > shown, this interleaving test takes only microseconds per iteration. > > > Depending on how precise you > > need to be, you could use $J as a subscript and you won't need to > > lock. > > I'm afraid that wouldn't help. It's true that values could be stored > under $J, but all sequencing information would be lost. The trick is > to determine the precise order in which the A's and B's are written. > We could use a lock of course, but that would cause processes to > block (thus invalidating the results of the test) and would be much > slower. > > > > === > Gregory Woodhouse > [EMAIL PROTECTED] > > "One must act on what has not yet happened." > --Lao Tzu > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
