Re: Thread Priority
Re: Thread Priority
- Subject: Re: Thread Priority
- From: AgentM <email@hidden>
- Date: Fri, 4 Nov 2005 15:09:22 -0600
In general, thread prioritizing should be avoided because it almost
never does what you might expect. Several issues crop up immediately
such as priority inversion and starvation. pthreads have APIs just to
handle that. The plan you suggest below is pretty much certain to
backfire- prioritizing ad-hoc will probably decrease performance
instead of improve it.
The priority/code maintainability and predictability trade-off is
seldom valuable so Butenhof in "Programming POSIX Threads" recommends
against thread prioritizing.
If you are having performance issues now, there are a number of
things you should experiment with:
1) increase/decrease your buffer pools
2) measure time spent per frame in each thread (use Shark or a
different sampler)
3) add code to monitor how quickly the buffers are passed through the
system
4) reduce polling- if you polling on a camera, make sure you aren't
grabbing frames faster than the camera can produce them (the iSight
pumps out 15 fps at 640x480)
Shark (in the CHUD tools) can help you pin-point where you spending
the most time. Optimize that and don't bother with the thread
priorities. Good luck!
On Nov 4, 2005, at 1:20 PM, Marc Van Olmen wrote:
hi,
I'm wondering if this is a good idea:
My application has 3 threads:
1. Reading
2. Image Composing
3. Display
The image composing thread (2) has a buffer of 15 frames, so 15
frames in advance can be generated. When ever a buffer comes
available the thread wakes up and generates another one.
The questions I have now is that I want to make sure that other
threads have more time available to increase responsiveness or even
in the future have more displays busy>
so I had the idea to play with thread priority.
When 15 frame buffers or free for rendering I give thread priority 80
When 14 frame buffers or free for rendering I give thread priority 73
...
When 1 frame buffers or free for rendering I give thread priority 20
0 frames the thread sleeps.
Would this be a good idea?
Or is it better that the thread has a constant priority?
Another question related, to make sure that my 2nd thread generates
enough frames in advance.
Should I also use the FixedPriority option:
if (mFixedPriority)
{
thread_extended_policy_data_t theFixedPolicy;
theFixedPolicy.timeshare = false; // set to true for a non-
fixed thread
BAIL_MSG_OSERROR(thread_policy_set(aMachPort,
THREAD_EXTENDED_POLICY, (thread_policy_t)&theFixedPolicy,
THREAD_EXTENDED_POLICY_COUNT), "cOS_Thread::SetPriority: failed to
set the fixed-priority policy");
}
I don't care about user responsive I want my application to run
smooth so sending the frames out at correct timing for smooth
animation.
|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
AgentM
email@hidden
|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden