oldPriority=
Priority([newPriority])
Unlike on OS 9 and Windows, On OS X setting a high priority will not
disable important parts of your computer such as the keybaord and hard
drive.
Priority calls the Psychtoolbox mex function
MachSetPriority. For
simple, OS-neutral control of process priority on OS X use
Priority. For
complicated, fine-grained, OS-specific control of process priority use
MachSetPriority.
At priority settings greater than 0, your script must limit MATLAB's use
of CPU time to stay within the limits specified by the priority value.
The consequence of failing to restrict the CPU time to the limits
specified by the priority values is that OS X will demote MATLAB back to
priority 0. You can check to see if this has happened by calling
Priority with no arguments.
1. Call "
WaitSecs"
2. Call
Screen('
Flip',...)
Both calls will sleep the main MATLAB thread, surrendering CPU time to
other threads on the system until the MATLAB thread is awakened.
WaitSecs sleeps the MATLAB thread for a specified period.
Screen('
Flip',...) sleeps the MATLAB thread until the next video blanking
interval.
The priority value corresponds to the proportion of the video frame
period during which MATLAB is guranteed 100 percent of CPU time:
GuaranteedCPUtimePerFramePeriod = priority/10 * framePeriod
If your computer has multiple video displays running at different frame
rates then
Priority will choose the shortest frame period.
The consequence of a thread exceeding the specified limits on CPU usage
are that the MACH kernel will revoke its real-time priority status.
However, the threshold at which the MACH kernel decices to revoke
priority is not known. We have observed that at 100% CPU usage the
Jaguar Mach kernel will revoke priority after 2.5 seconds, indepent of
the CPU time requested when setting priority.
Note that if you change the video frame rate after setting priority then
the framePeriod which
Priority used when setting the priority level will
no longer match the true frame period. Therefore you should change the
priority level after changing the video mode and not before.
Because the OS X update process causes setjmp calls within MATLAB to
delay for up to about 13ms,
Priority kills the system update process when
setting any priority greater than 0.
Priority will restart the update
proceess when setting priority back to 0, but only if it was
Priority
itself which killed the update process. If update was already killed
when
Priority was set to a level greater than 0 then priority will not
restart the update process when restoring priority to 0. You can use
KillUpdateProcess and
StartUpdateProcess to kill and restart the update
process without using Prioirity. Because killing and starting the
update process sometimes requires that an adminstrator password be
entered in the MATLAB command window, you might prefer not kill and
restart with every call to
Priority, but instead to do this only at the
beginning and end of a MATLAB session by using
KillUpdateProcess and
StartUpdateProcess.
Due to improvements in the realtime behaviour of OS-X 10.4.7 and later,
it is no longer neccessary to kill the update process. If
Priority()
detects such an OS version, it will not kill update anymore. This
provides an over hundred-fold speedup in the execution of
Priority(). If
you think that timing gets worse on your system, you can check the timing
by running the test command '
TestMATLABTimingOSX'. If you rather want
Priority to kill the update process on 10.4.7 and later, please create a
file with the name '
AlwaysKillUpdate' in the Psychtoolbox root folder to
enforce killing of the update process. The content of the file does not
matter at all.
For the Windows version of
Priority (and
Rush), the priority levels set
are "process priority levels". There are 3 priority levels available,
levels 0, 1, and 2. Level 0 is "normal priority level", level 1 is "high
priority level", and level 2 is "real time priority level". Combined with
thread priority levels, they determine the absolute priority level of the
matlab thread. Threads are executed in a "round robin" fashion on
Windows, with the lower priority threads getting cpu time slice only
when no higher priority thread is ready to execute. Currently, no tests
had been done to see what tasks are pre-empted by setting the Matlab
process to real-time priority. It does seem to block keyboard input,
though, so for example if you have a clut animation going on at priority
level 2, then the force-quit key combo (Ctrl-Alt-Delete) does not work.
However, the keyboard inputs are still sent to the message queue, so
GetChar or
GetClicks still work if they are also called at priority level
2.
GNU/Linux supports priority levels between 0 and 99. Zero means standard
non-realtime timesharing operation -- Play fair with all other
applications. Increasing values greater than zero mean realtime mode: The
Matlab/Octave process is scheduled in round robin realtime mode with a
priority corresponding to the given number - higher means better, but
also more likelihood of interfering with system processes. Try to stick
to a level of 1 unless you know what you're doing!
In realtime mode, PTB will also try to lock down all of Matlab/Octaves
memory into physical RAM, preventing it from being paged out to disk by
the virtual memory manager. If it works, it's great! However, the amount
of lockable memory is restricted to max. 50% of installed RAM memory on
a standard Linux setup, so if Matlab/Octave/your experiment would need
more than 50% of available system memory, this will fail. PTB will output
an informative warning in this case, but continue otherwise unaffected.
Realtime scheduling will be still effective, you'll just lose the bonus
of memory locking.
Be careful not to create any uninterruptible infinite loops in your code
when running realtime, otherwise your system may lock up, reqiring a
hard reboot!
see also OS X:
Rush
see also Windows:
Rush
see also OS 9:
Rush,
ScreenTest,
RushTest,
LoopTest
Psychtoolbox/PsychPriority/Priority.m