Re: Need help controlling process priorities and sync

New Message Reply Date view Thread view Subject view Author view

Bernard Leclerc (bleclerc++at++cae.ca)
Tue, 5 Nov 1996 17:35:12 -0500


Jim Gullen wrote:

> My resources are:
> 1-pipe, 2-cpu Onyx RE2
> IRIX 5.3
> Performer 2.0
>
> My question is simply
> How can I guarantee that my front-end simulation executes
> at a lower priority than draw, cull, AND app?
>
> By this I mean that the sim must be *immediately* pre-empted
> by Unix whenever draw, cull, or app request cpu control.
>
> Specifically, and ignoring non-preemptive low-level i/o
> on behalf of the sim, how do I guarantee that the app can
> immediately resume upon completion of a pfSync or pfFrame
> event, do its thing, then yield the cpu (to an awaiting lower
> priority process) in initiating its next event wait?

Since you have 2 CPUs, I assume (and suggest) you run the simulation
process on CPU0 while the Performer process runs on CPU1. I also assume a
shared-memory segment is used to exchanged data between the two processes.

In your Performer process, use pfuLockDownProc(), pfuRunProcOn() and
pfuPrioritizeProcs() to lock your visual process on CPU1, isolate the CPU
from other processes and assign a non-degrading priority. This setup
should permit the APP/CULL/DRAW to run at its best without being
interrupted and without interrupting the simulation process which will be
running on a different CPU.

--
Bernard Leclerc			CAE Electronics Ltd., 8585 Cote De Liesse
Technical Leader		Saint-Laurent, Quebec, Canada, H4L-4X4
3-D Graphics Applications	tel: +1 514 341 2000 extension 2275
bleclerc++at++cae.ca			fax: +1 514 340 5496
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:53 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.