$WAITFR behaviour

[John Gillings]

Barry,

If one of your objectives is to have the same code running on multiple platforms, then it's imperative that you abstract out your synchronization mechanism and express it in application terms. (It sounds like I had the same visualisation as Hoff - an "escapement" mechanism, hence my suggestion of Tick and Tock.)

Hide all the OS specific stuff under a layer of routines that your application calls. When you port to another platform, you have all the OS specific stuff isolated in a few routines, so it's potentially easier to do the port. Of course, it won't hurt to look at the synchronization primitives available on each of your potential target platforms to make sure you're not choosing something that's difficult or impossible in one of the environments.

From what you've now described it sounds like the mechanism you want is more like a starters gate for a horse race. Your slaves look like this:

loop
wait at gate
do something
next

and your master is:

timed loop
open gate
close gate
next

The biggest detail is to decide if the master needs to wait for all the slaves to be ready at the gate before opening it, and to make sure all the slaves are through the gate before arming (closing) it for the next cycle. From your initial description of the problem, it seems to be that IS necessary, since you care about slaves missing cycles. As you've already realised, that means the master needs to know how many slaves are involved, and therefore requires some kind of registration.

If you're not too concerned about missed events, the most obvious OpenVMS implementation is a lock with the master cycling EX-NL and the slaves cycling CR-NL, as Claus has suggested. The master should be able to convert EX-NL-EX very quickly without starving out the slaves because the NL-CR conversions of the slaves should be already queued in front of the master.

Another possible option is to eliminate the master. Let the slaves do their own timing, but have some mechanism that keeps track of where each is up to, so that faster running slaves stop and wait for slower ones.

Your mystery of changed behavious under SHOW PROCESS/CONTINUOUS is easily explained. There are a few $GETJPI items that are globally accessible, but many need to be gathered from the context of the target process. The mechanism is a "special kernel AST" sent to the process. It is therefore made computable to gather the data and send it back. When the AST has completed, the process returns to the LEF or CEF wait, at which point it retests the EFWM. Since SHOW PROCESS/CONTINUOUS is continually sending $GETJPI "wake ups", the process is much more likely to see the set event flag.

Has Hoff has suggested, see the IDSM for the gory details of how event flags are implemented. I think there's a list of waiting processes associated with the event flag which are put into COM state when the flag is set, but, since there are other events which can make the process computable (like the $GETJPIs) the flag is always tested when the process actually runs (by which time it may have been cleared).

[Barry Alford]

No need to consult the IDSM because after having my suspicions confirmed by those whose fingers have been burned by event flags I will definitely NOT be using common event flags to signal between processes like I had envisaged.

John - re missing cycles: I said that I may not mind missing an odd cycle here and there, but loosing almost all of them was intolerable!

The advantage of running under a master clock is that it gives the ability to "freeze" all the slave processes simply by pausing the master (this is an application requirement). In a free-running ex-slaves scenario, each process will be passed and monitor this "freeze" flag itself.

In any event ('scuse the pun!), whether
free-running or slave, the processes have to be thread-safe.

As I mentioned before, I am reluctant to use other VMS mechanisms as we have to port to another platform (big W). If we need a master clock, I would first investigate using the $HIBER/$WAKE mechanism which compares to
the event-driven methods used by another OS...

[Barry Alford]

Ok, I got confirmation that $WAITFR could not be relied on to do what I wanted. I got a lot of valuable suggestions on how to achieve master/slave synchronisation, and if we need to go that route I will consider these proposals, especially the $HIBER/$WAKE mechanism.

Thanks for all who participated; as ever, this forum is a rich and rewarding place to be.