Re: Are threads accessing the same memory space
From: Joseph M. Newcomer (newcomer_at_flounder.com)
Date: 08/22/04
- Next message: benben: "Dialog doesn't pop"
- Previous message: Joseph M. Newcomer: "Re: generic message handler"
- In reply to: Scott McPhillips [MVP]: "Re: Are threads accessing the same memory space"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 22 Aug 2004 04:40:59 -0400
Actually, of course, it is much worse than that. If a thread is starved because a
high-priority thread is running, the Balance Set Manager will eventually invoke
anti-starvation by boosting the starved thread to priority 15 and giving a double
timeslice.
And if a thread has high priority, it still doesn't guarantee that the pages it touches
are actually going to be in memory when they are required, although there is a fairly good
chance that they will be. But a page fault can take tens of milliseconds to respond to.
All threads, of course, have access to the memory space of the process, but as to whether
or not they are touching the "same" memory, e.g., common memory shared between them, as
you observe cannot be determined without examining the code. But if there is
synchronization, responsiveness and priorities are affected by synchronization issues. In
addition, if a low-priority thread locks a mutex or CRITICAL_SECTION, it can therefore be
starved by other higher-priority threads which hog the machine. This means that a
high-priority thread that needs that space will now be forced to respond with the
low-priority responsiveness, since it will remain blocked until the low-priority thread
completes. This problem is known as the "priority inversion" problem, and is the realtime
programmer's fear, since it is not dissimilar to the problem of deadlock. Analysis
techniques such as Rate Monotonic Analysis usually have to be used to isolate such
problems, but in a non-realtime system there is rarely any way to deal with the results of
the analysis (in a true realtime operating system, this is easily handled by the nature of
the system, but in a general operating system, you are usually out of luck)
I don't recognize the display of "highest" and "time critical", but if "time critical"
means priority 15, then of course this makes the threads lower than all kernel threads,
including the file system, the balance set manager itself, and other driver threads and
kernel service threads that may be running. Since a normal process can never have threads
above priority 15 (and a "realtime" process can never have threads below priority 16, and
therefore a mix of 16..31 and 1..15 threads in a give process are impossible) I am
presuming that "time critical" means priority 15, which means they are pretty much
second-class citizens in terms of scheduling.
Running the process as "realtime" would allow a time-sensitive thread to run at priority
31. But this means it can preempt the entire file system, critical kernel services, and of
course all user threads. The Balance Set Manager does not extend to handling realtime
threads, so there is no anti-starvation mechanism that can come into play. And creating a
realtime process usually requires special privileges not normally granted to users.
I'd very much suspect the problem is in buffering, which is the only way to handle the
issues of threading and timing. Note that a time-critical thread that is running will
preempt the entire GUI, but the Balance Set Manager will let it get in every 3 to 4
seconds to do something. And it can boost several starved threads, introducing arbitrary
delays into the hundreds of milliseconds.
Generally, glitches in sound cannot be solved by thread priority games, but must be
handled by buffering larger amounts of data. Thread priorities are notoriously unreliable
(in general-purpose operating systems) as a means of controlling responsiveness in the
long term, and only barely viable in controlling responsiveness in the short term. I've
certainly used them, extremely carefully, to guarantee responsiveness to a
high-performance RS-485 network. And we paid a heavy price in terms of responsiveness when
the network traffic was heavy (but without the priority games, it wouldn't work at all).
joe
On Thu, 19 Aug 2004 19:09:19 -0500, "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp>
wrote:
>rj wrote:
>
>> I have the following threads in the debug
>> Currently activated--> 3348 WinMain AfxInternalPumpMessage Normal 0
>> 2236 _threadstartex AfxInternalPumpMessage Highest 0
>> 2644 _threadstartex AfxInternalPumpMessage Normal 0
>> 3408 Win32 Thread 7ffe0304 Time Critical 0
>> 2176 Win32 Thread 7ffe0304 Time Critical 0
>> 2120 Win32 Thread 7ffe0304 Time Critical 0
>>
>> My gui does vo-ip and the sound skips i am suspecting threading issues.
>> am i anywhere close?
>> thanks
>> rj
>>
>>
>
>There is no way to know whether they are accessing the same memory
>without examining the code.
>
>But the fact that you have three "Time Critical" threads plus one
>"Highest" priority thread shows that you are asking for the impossible.
> Perhaps you don't understand priority. Only one thread gets priority
>at any time. When that thread has priority all other threads are suspended.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
- Next message: benben: "Dialog doesn't pop"
- Previous message: Joseph M. Newcomer: "Re: generic message handler"
- In reply to: Scott McPhillips [MVP]: "Re: Are threads accessing the same memory space"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
