tuck@iris.ucdavis.edu (Devon Tuck) (11/04/88)
I am in the process of converting an asynchronous I/O-based system,
designed to poll a line from the National Weather Service for data, written
in FORTRAN, to our Xenix 386/20 system. It is necessary for at least 3
different programs to have access to an input buffer which is constantly
being filled. It would be convinient if there were some way to use C's
shared memory routines, shmctl(), shmget(), shmat() to keep all of the
Fortran programs' buffer referencing the same piece of memory dynamically.
My problem is this, I need to either find a way to simulate a "monitor
common block" in LPI-FORTRAN, *or* find a way to change the address of each
program's buffer pointer so they all reference the same chunk of C shared
memory, so that I may immediately obtain new buffer input in each of the
programs.
The closest solution I have found, is to create a host subroutine which
passes the buffer array of a program into shared memory, loads it with the
new information, and then returns it. The problem with this is, the loop
which checks for this new information will most probably be an infinite
loop, and continual execution of the shared memory routine could seriously
degrade performance.
Any ideas?
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Devon Tuck {tuck@iris.ucdavis.edu}
Xenix Sys-Admin, Hydrologic Engineering Center Technical Assistance Division
US Army Core of Engineers, Davis, CA. (916) 756-1104 ext. 18
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (11/06/88)
In article <3246@ucdavis.ucdavis.edu> tuck@iris.ucdavis.edu (Devon Tuck) writes: >in FORTRAN, to our Xenix 386/20 system. It is necessary for at least 3 >different programs to have access to an input buffer which is constantly >being filled. >The closest solution I have found, is to create a host subroutine which >passes the buffer array of a program into shared memory, loads it with the >new information, and then returns it. The problem with this is, the loop >which checks for this new information will most probably be an infinite >loop, If I understand your situation correctly, you want several programs to wait on an update of a shared memory segment without sitting in an polling loop. One way to do this would be to create a fifo (with mknod(1)) for each process and write a byte to each of them when you update the segment. The other processes can do a blocking read on the fifo. This is just the first thing that came to mind - there are probably other ways to do this. -- Jon Zeeff Ann Arbor, MI umix!b-tech!zeeff zeeff@b-tech.ann-arbor.mi.us
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (11/06/88)
In article <4918@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >In article <3246@ucdavis.ucdavis.edu> tuck@iris.ucdavis.edu (Devon Tuck) writes: >>The closest solution I have found, is to create a host subroutine which >>passes the buffer array of a program into shared memory, loads it with the >>new information, and then returns it. The problem with this is, the loop >>which checks for this new information will most probably be an infinite >>loop, > >If I understand your situation correctly, you want several programs to >wait on an update of a shared memory segment without sitting in an >polling loop. One way to do this would be to create a fifo (with >mknod(1)) for each process and write a byte to each of them when you >update the segment. The other processes can do a blocking read on the >fifo. This is just the first thing that came to mind - there are >probably other ways to do this. Yes, there are message queues and semaphores. I suggest messages queues as being the best mechanism, but that's because I don't like semaphores anyway ;-) Have the updating process place messages on the queue for each process which is to be awoken - or you could signal a semaphore, if you are into the semaphore idiom. An amusing solution, for those people with file locking but no shared memory [ Berzerkeley UNIX folks ] is to create a file to hold all the buffers and use file locking to insure mutual exclusion. Hadn't thought of that solution ... -- John F. Haugh II +----Make believe quote of the week---- VoiceNet: (214) 250-3311 Data: -6272 | Nancy Reagan on Richard Stallman: InterNet: jfh@rpp386.Dallas.TX.US | "Just say `Gno'" UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------