mccalpin@perelandra.cms.udel.edu (John D. McCalpin) (03/08/91)
I am working on a FORTRAN application that needs to sit and wait for certain data files to be completely written. The basic loop is OPEN(in_unit,....) 8888 READ(in_unit,ERR=8888,END=8888) data CLOSE(in_unit) This works fine, but uses up lots of system time that would be better spent by the other process that is supposed to be writing the data! On the Silicon Graphics machines, there is a nice function called 'sginap(i)' which: -- with an argument of 0, will release control to any other process with the same or higher priority; or -- with an argument i>0, will sleep for 'i' clock ticks. The modified code segment: OPEN(in_unit,....) 8888 idummy = sginap(0) READ(in_unit,ERR=8888,END=8888) data CLOSE(in_unit) runs much more efficiently. I cannot use the normal 'sleep()' routines, since the actual latencies involved are much smaller than 1 second, and the OPEN/READ/CLOSE sequence needs to be done several times per second. Is this functionality available in a more standard UNIX call? Does AIX have this functionality? This is important, since I really want to run the application on a network of IBM 320's sharing files via NFS. -- John D. McCalpin mccalpin@perelandra.cms.udel.edu Assistant Professor mccalpin@brahms.udel.edu College of Marine Studies, U. Del. J.MCCALPIN/OMNET
richard@locus.com (Richard M. Mathews) (03/09/91)
mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes: >The modified code segment: > OPEN(in_unit,....) > 8888 idummy = sginap(0) > READ(in_unit,ERR=8888,END=8888) data > CLOSE(in_unit) >runs much more efficiently. >I cannot use the normal 'sleep()' routines, since the actual latencies >involved are much smaller than 1 second, and the OPEN/READ/CLOSE >sequence needs to be done several times per second. Any system call should have the property of giving up control to a higher priority process. I am almost certain that is true in AIX/370 and AIX PS/2. I am less certain on the 6000. Try getpid(). (Or does sginap go farther and explicitly put you at a low priority?) Better yet, can you use select()? This will let you sleep until there is data available -- no shorter, no longer (ignoring the time it takes for you to make it to the front of the run queue). Richard M. Mathews Freedom for Lithuania richard@locus.com Laisve! lcc!richard@seas.ucla.edu ...!{uunet|ucla-se|turnkey}!lcc!richard
jim@tct.uucp (Jim Kunzman) (03/10/91)
There is indeed a C call which will solve your problem. It is usleep() and
you can man usleep for the details. Granularity is microseconds (hence the u),
but I wouldn't bet the accuracy would be much closer than a few milliseconds,
although I could be wrong. Hope this helps.
--
Jim Kunzman at Teltronics/TCT <jim@tct.uucp>, <uunet!pdn!tct!jim>
!(This space intentionally left blank.)bengsig@dk.oracle.com (Bjorn Engsig) (03/11/91)
Article <MCCALPIN.91Mar7210817@pereland.cms.udel.edu> by mccalpin@perelandra.cms.udel.edu (John D. McCalpin) says: |'sginap(i)' which: | -- with an argument of 0, will release control to any other | process with the same or higher priority; or | -- with an argument i>0, will sleep for 'i' clock ticks. | |I cannot use the normal 'sleep()' routines, since the actual latencies |involved are much smaller than 1 second, You have at least two options that do more or less what you want: - use usleep(), which is available in C, so you might need a fortran interface, but I actually doubt it. It will sleep for a number of micro seconds. - Use kernel extensions. There are a number of kernel extension that handle scheduling and related matters. -- Bjorn Engsig, ORACLE Corporation, E-mail: bengsig@oracle.com, bengsig@oracle.nl