MICHAL@KUHUB.CC.UKANS.EDU (Merlin The Magician) (07/19/88)
I am stuck with the following problem and I think that I am
overlooking something. Part one of my problem was rather easy,
problem is really with part 2. Here it comes:
1. I needed to "synchronize" the running of several processes. Those
processes were SPAWNed from different accounts IN THE SAME GROUP. It
was easy enough to create a (temporary) event flag cluster that all
these processes shared and make 'em all wait for a specific event
flag. I did this using two very simple programs that I called WAIT
and SIGNAL. Essentially when SIGNAL is run, the WAIT program quits
running (the event flag is set).
2. What I need to do is the following:
I need to declare an AST routine in a program. The AST routine
should be called when (preferably) an event flag is set. Problem is I
could not find a way to let the program run - apparently you must
WAIT for the event flag to be set. I need to let the program run and
be interrupted by an event flag being set.
Any of you Gurus out there think this is childlessly easy ?
Thanks a lot ...
+-----------------------------------------------------------------------------+
| Michal Chmielewski K K U U |
| Academic Computing Services K K U U |
| University of Kansas K K U U |
| Lawrence, KS 66045 KK U U |
| Audio : 1-(913)-864-0443 K K U U |
| BitNet: michal@ukanvax.bitnet K K U U |
| michal@ukanvm.bitnet K K UUUUU |
+-----------------------------------------------------------------------------+
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (07/25/88)
> I am stuck with the following problem and I think that I am > overlooking something. Part one of my problem was rather easy, > problem is really with part 2. Here it comes: > > 1. I needed to "synchronize" the running of several processes. Those > processes were SPAWNed from different accounts IN THE SAME GROUP. It > was easy enough to create a (temporary) event flag cluster that all > these processes shared and make 'em all wait for a specific event > flag. I did this using two very simple programs that I called WAIT > and SIGNAL. Essentially when SIGNAL is run, the WAIT program quits > running (the event flag is set). > 2. What I need to do is the following: > I need to declare an AST routine in a program. The AST routine > should be called when (preferably) an event flag is set. Problem is I > could not find a way to let the program run - apparently you must > WAIT for the event flag to be set. I need to let the program run and > be interrupted by an event flag being set. I don't know how to solve part 2 given that you're using the mechanism of part 1. However, depending on how close the synchronization needs to be, I have a suggestion for another way of doing things: You could set up mailboxes for each process to be synchronized, and instead of using event flags, have each process issue a $QIO to its mailbox with your AST routine as the completion AST routine. Make sure the AST routine queues another I/O request to the mailbox. Then have the process that would have set the event flag write to each of the mailboxes instead.
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (07/25/88)
...I needed to "synchronize" the running of several processes. Those processes were SPAWNed from different accounts IN THE SAME GROUP. It was easy enough to create a (temporary) event flag cluster that all these processes shared and make 'em all wait for a specific event flag. I did this using two very simple programs that I called WAIT and SIGNAL. Essentially when SIGNAL is run, the WAIT program quits running (the event flag is set). What I need to do is the following: I need to declare an AST routine in a program. The AST routine should be called when (preferably) an event flag is set. Problem is I could not find a way to let the program run - apparently you must WAIT for the event flag to be set. I need to let the program There is no way to have an AST triggered by the setting of an event flag. If you step back from this way of looking at things, and simply ask for a way for a process to set off an AST in another process, things are a bit different. Unfortunately, VMS provides no direct way to do exactly this; but you can get the effect in at least three ways, listed in order of increasing performance and difficulty of implementation. 1. Use a mailbox. A process can get an AST when data is placed in a mailbox, or a completion AST if it has a pending read on the mailbox. The mailbox message can carry additional data describing the reason for the AST if you like, or it can be a dummy message. 2. Use the lock manager and blocking AST's. The trick is for the receiver to hold a lock, requesting a blocking AST. The sender attempts to obtain a lock, which the receiver's lock will not allow. The receiver then receives a blocking AST. The code needs to be organized carefully so that the initial state is restored after the "cross-process AST" has been sent (unless you never intend to send another one). For good efficiency, you should actually take out the lock only once, and use lock conversions thereafter. This method, unlike the other two, will work cluster-wide. 3. If you are a kernel-mode hacker, it isn't hard to write a small piece of code that delivers a kernel-mode AST to another process, where it will run code you have placed into system space. That code, in turn, will queue a user-mode AST to the process. Code to do this has been posted to the net at least once, but I'm afraid I don't have a copy. A good model for everything you need except perhaps allocating the system-space memory is the $FORCEX system service, which using this mechanism to force another process to execute a $EXIT. -- Jerry
jkingdon@chinet.chi.il.us (James Kingdon) (07/26/88)
When I had to do this, I just abandoned event flags and used locks as follows: 1. The program that wants to be interrupted later lakes out an exclusive mode lock, with a blocking AST. Then it goes about it's business. 2. When the other program wants to interrupt it, it asks for the lock (also exclusive mode). The first program executes the blocking AST, which does whatever you want to do, and then converts the lock to null, and then converts the lock back to exclusive (this allows the second program to wait for the first one to do something). One thing to be careful of in using locks for this kind of thing is that new lock requests and lock conversions are placed in separate queues. I don't remember whether this might cause a problem in this particular example, but I remember I did think of some scenerio where things could get granted in the wrong order. The fix is simple: When requesting a new lock, request a null mode lock, then convert it to exclusive.