By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,454 Members | 3,191 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,454 IT Pros & Developers. It's quick & easy.

Is there any reason to avoid a busy while loop?

P: n/a
I have a real-time simulation where the logic flows most easily with a busy
while loop...

while (continueFlagSet)
{
if (EventDue)
ProcessNextEvent
}

Now, is there any thing to be concerned about here? With older versions of
Windows, I wouldn't have trusted the operating system to share the processor,
so I would have put an "else Sleep(0)" at the bottom of the loop, but this is
2005, and shouldn't I leave it to the operating system to manage processes,
and threads, without any hints from me?

When i'm running the application, there isn't any obvious impact on my other
Windows apps, or other threads in the same app, but I haven't tested this
thoroughly.

I am mindful of an excellent essay I read where the author listed "Sleep" as
one of the common sources of problems in windows apps, and which is almost
never needed. http://www.flounder.com/badprogram.htm
Nov 17 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
wait on event, then I don't see an issue. continueFlagSet should be a
another event (i.e. reset event) or syncd when set and tested if set from
another thread.

--
William Stacey [MVP]

"Javaman59" <Ja*******@discussions.microsoft.com> wrote in message
news:BD**********************************@microsof t.com...
I have a real-time simulation where the logic flows most easily with a busy
while loop...

while (continueFlagSet)
{
if (EventDue)
ProcessNextEvent
}

Now, is there any thing to be concerned about here? With older versions of
Windows, I wouldn't have trusted the operating system to share the
processor,
so I would have put an "else Sleep(0)" at the bottom of the loop, but this
is
2005, and shouldn't I leave it to the operating system to manage
processes,
and threads, without any hints from me?

When i'm running the application, there isn't any obvious impact on my
other
Windows apps, or other threads in the same app, but I haven't tested this
thoroughly.

I am mindful of an excellent essay I read where the author listed "Sleep"
as
one of the common sources of problems in windows apps, and which is almost
never needed. http://www.flounder.com/badprogram.htm

Nov 17 '05 #2

P: n/a
Thanks...

A sloppy example on my part. "if (EventDue)" is referring to a logical
event, not a system event which I can wait on. eg, in a movie playing system,
it would be "if (next frame due)". I'm processing up to 200 events per
second. I don't think I can afford the overhead of creating system events,
and waitng on them.

Yes, continueFlagSet is handled with Interlocked, which I think does the job
of synchronization.

Javaman

"William Stacey [MVP]" wrote:
wait on event, then I don't see an issue. continueFlagSet should be a
another event (i.e. reset event) or syncd when set and tested if set from
another thread.

--
William Stacey [MVP]

"Javaman59" <Ja*******@discussions.microsoft.com> wrote in message
news:BD**********************************@microsof t.com...
I have a real-time simulation where the logic flows most easily with a busy
while loop...

while (continueFlagSet)
{
if (EventDue)
ProcessNextEvent
}

Now, is there any thing to be concerned about here? With older versions of
Windows, I wouldn't have trusted the operating system to share the
processor,
so I would have put an "else Sleep(0)" at the bottom of the loop, but this
is
2005, and shouldn't I leave it to the operating system to manage
processes,
and threads, without any hints from me?

When i'm running the application, there isn't any obvious impact on my
other
Windows apps, or other threads in the same app, but I haven't tested this
thoroughly.

I am mindful of an excellent essay I read where the author listed "Sleep"
as
one of the common sources of problems in windows apps, and which is almost
never needed. http://www.flounder.com/badprogram.htm


Nov 17 '05 #3

P: n/a
> Yes, continueFlagSet is handled with Interlocked, which I think does the
job
of synchronization.


Yes it does. As to locking (side issue), on my 1.86GH PMobil laptop, I can
get about 27 Million locks per second including an increment operation (per
test below). In most cases, the lock overhead is not going to be a
bottleneck for your app. It is too bad that the documentation seems to make
a big deal out of lock overhead, because if done right, is not really an
issue in most cases. So in terms of your 200 work items per second
requirement, locking overhead is almost nothing. Naturally, you could have
locking bugs, but that is another issue. Interlocked should be fine for
your int however.

object sync = new object();
Stopwatch sw = new Stopwatch();
sw.Start();
for ( int i = 0; i < 27000000; )
{
lock ( sync )
{
i++;
}
}
sw.Stop();
Console.WriteLine("Sec:{0} ms:{1}", sw.Elapsed.Seconds,
sw.Elapsed.Milliseconds);

--
William Stacey [MVP]

Nov 17 '05 #4

P: n/a
Thanks William, that's very interesting. I'll never worry about the time for
getting a lock again.

"William Stacey [MVP]" wrote:
Yes, continueFlagSet is handled with Interlocked, which I think does the
job
of synchronization.


Yes it does. As to locking (side issue), on my 1.86GH PMobil laptop, I can
get about 27 Million locks per second including an increment operation (per
test below). In most cases, the lock overhead is not going to be a
bottleneck for your app. It is too bad that the documentation seems to make
a big deal out of lock overhead, because if done right, is not really an
issue in most cases. So in terms of your 200 work items per second
requirement, locking overhead is almost nothing. Naturally, you could have
locking bugs, but that is another issue. Interlocked should be fine for
your int however.

object sync = new object();
Stopwatch sw = new Stopwatch();
sw.Start();
for ( int i = 0; i < 27000000; )
{
lock ( sync )
{
i++;
}
}
sw.Stop();
Console.WriteLine("Sec:{0} ms:{1}", sw.Elapsed.Seconds,
sw.Elapsed.Milliseconds);

--
William Stacey [MVP]

Nov 17 '05 #5

P: n/a

"William Stacey [MVP]" <st*****@mvps.org> wrote in message
news:eC**************@TK2MSFTNGP15.phx.gbl...
Yes, continueFlagSet is handled with Interlocked, which I think does the
job
of synchronization.


Yes it does. As to locking (side issue), on my 1.86GH PMobil laptop, I
can get about 27 Million locks per second including an increment operation
(per test below). In most cases, the lock overhead is not going to be a
bottleneck for your app. It is too bad that the documentation seems to
make a big deal out of lock overhead, because if done right, is not really
an issue in most cases. So in terms of your 200 work items per second
requirement, locking overhead is almost nothing. Naturally, you could
have locking bugs, but that is another issue. Interlocked should be fine
for your int however.

object sync = new object();
Stopwatch sw = new Stopwatch();
sw.Start();
for ( int i = 0; i < 27000000; )
{
lock ( sync )
{
i++;
}
}
sw.Stop();
Console.WriteLine("Sec:{0} ms:{1}", sw.Elapsed.Seconds,
sw.Elapsed.Milliseconds);

--
William Stacey [MVP]


While I agree that taking a lock is not that expensive when there is no
contention, it's still not the right thing to do when all you need is
perform an atomic thread-safe operation like incrementing or decrementing a
variable.
Taking a lock is still 20 times slower than a Interlocked.Increment(ref i);

Willy.

Nov 17 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.