Re: threads

From:

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam>

Newsgroups:

microsoft.public.vc.language

Date:

Thu, 20 Dec 2007 09:09:48 -0600

Message-ID:

<OUqvGoxQIHA.4272@TK2MSFTNGP06.phx.gbl>

"Aaron" <Aaron@discussions.microsoft.com> wrote in message
news:4F70BCFB-1F4B-4B15-B81C-9B0608B2B0C5@microsoft.com...

Hmmmm ......ok .... but there is still a couple things not making sense.

I've experimented with priorities ... I have the application set at normal
priority, but there is just one small piece of code that shouldn't be
interrupted .... you know, the command that reads or writes the audio
buffer.

The problem is that it IS interrupted ..... even though that callback
function (which is a very small part of the overall code) is set to
highest
priority .... even though there is a beginCriticalSection() before it
.....
I'm running out of things to do.

Regardless of priority, your thread will stop and wait if it needs a
critical section (or any other lock) that someone else owns. The OS may or
may not boost the priority of the current owner.

I was thinking about trying mutex or monitor commands but .... well they
lock an object ... and I don't really need to lock any object, just need
to
tell the thread to not reliquish control while that object is being dealt
with.

And second, the callback is a high level (non member) function ... and
since
I can't declare a global mutex ... nor is the audio buffer a global object
..... hmmmm.

How is it that programs like cakewalk/pro studio .... pro recording
programs
deal with this ..... there has to be a way to ensure that the program will
not be interruped during that time when it is dealing with the audio
buffer ??

Thanks
Aaron

"Nathan Mates" wrote:

In article <3A57A2C0-D1EE-42AC-B339-67BF88FA2C01@microsoft.com>,
=?Utf-8?B?QWFyb24=?= <Aaron@discussions.microsoft.com> wrote:

Simple question:
I have a callback function that gets interrupted by something
...... I check the system time before and after a particular
operation ... it usually takes ~150000 ticks ..... but once in a
while it takes much longer. It is a single operation .... reading a
buffer (which is not locked) .......

Simple question, tough answer. The short summary of the answer is
'deal with it.' The longer version of the answer is that Windows is
*not* a realtime operating system, where things can be guaranteed to
happen. All sorts of things -- from other threads to disk access
(memory swapped out, etc) can demand processor time. If you pull up
the task manager (hit ctrl-alt-delete, and pick 'Task Manager') you
can easily see what processes are using CPU time. You can also see
which processes are hitting the disk, though you may need to enable
other columns.

Programatically, the SetThreadPriority function -- see articles
like http://msdn2.microsoft.com/en-us/library/ms686277.aspx for how to
adjust things. However, if you're using this to set things to anything
higher than THREAD_PRIORITY_ABOVE_NORMAL, you're being *very*
unfriendly to other apps. I wouldn't want to run any apps that
misbehave in that way. Basically, if you're only running this app on
your home system, higher priorities are acceptable. Please don't
inflict such code on anyone else.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A.
Heinlein