creating ManualResetEvent in thread

Bob,

There are two separate issues here. The first is whether or not to use
kernel stuff in a thread. If by kernel stuff you mean things like
ManualResetEvent instances, then the first statement is wrong, as it is
perfectly fine to use a ManualResetEvent in threads. As a matter of fact,
they are usually used to deal with synchronizing threads.

As for whether or not it will affect your performance, what is the
similar mechanism that you are comparing it against?
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"bbg" <bb*@discussions.microsoft.comwrote in message
news:E5**********************************@microsof t.com...

Hi all,

I read somewhere "using kernel stuff in thread is not good.."

if ManualResetEvent object is created in thread but not actually used,
will
it affect performance?

Bob

bbg wrote:

I read somewhere "using kernel stuff in thread is not good.."

Where? Sounds like a misinterpretation at best, and a completely bogus
piece of advice at worst.

if ManualResetEvent object is created in thread but not actually used, will
it affect performance?

Just one? Almost certainly not. But if you're not going to use it, why
create it?

Hi Nicholas,

I am not interested in what other mechanism is available for synchronizing
threads. What I am curious is that just creating ManualReset object but not
using at all in thread will degrade performance..

Bob
"Nicholas Paldino [.NET/C# MVP]" wrote:

Bob,

There are two separate issues here. The first is whether or not to use
kernel stuff in a thread. If by kernel stuff you mean things like
ManualResetEvent instances, then the first statement is wrong, as it is
perfectly fine to use a ManualResetEvent in threads. As a matter of fact,
they are usually used to deal with synchronizing threads.

As for whether or not it will affect your performance, what is the
similar mechanism that you are comparing it against?
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"bbg" <bb*@discussions.microsoft.comwrote in message
news:E5**********************************@microsof t.com...

Hi all,

I read somewhere "using kernel stuff in thread is not good.."

if ManualResetEvent object is created in thread but not actually used,
will
it affect performance?

Bob

bbg wrote:

I am not interested in what other mechanism is available for synchronizing
threads.

Well, you should be, since it's very much related to your original post.

Whether you are interested or not, it _is_ an example of a specific
reason ManualResetEvents are used in a thread. It's an obvious
counter-example to the "using kernel stuff in thread is not good" you
mentioned, so it's a natural thing for Nicholas to bring up.

There's no need for you to point out that you're not interested. If
you're not interested, just ignore it and move on.

What I am curious is that just creating ManualReset object but not
using at all in thread will degrade performance..

Then you may want to consider answering the question Nicholas asked, so
that he can provide more specific advice.

And for what it's worth, there's no such thing as "using kernel stuff"
_not_ in a thread. All code executes in a thread. You may only have a
single thread in which your code executes, but there's still a thread.

Pete

I am working on window service application in which threads come and go
and found ManualResetEvent was created but not used(nobody waiting).
So I became curious how creating unnecessary ManualResetEvent will affect
performance.

About "using kernel stuff in thread is not good..",

http://msdn.microsoft.com/msdnmag/is...urrentAffairs/

Bob

"Peter Duniho" wrote:

bbg wrote:

I am not interested in what other mechanism is available for synchronizing
threads.

Well, you should be, since it's very much related to your original post.

Whether you are interested or not, it _is_ an example of a specific
reason ManualResetEvents are used in a thread. It's an obvious
counter-example to the "using kernel stuff in thread is not good" you
mentioned, so it's a natural thing for Nicholas to bring up.

There's no need for you to point out that you're not interested. If
you're not interested, just ignore it and move on.

What I am curious is that just creating ManualReset object but not
using at all in thread will degrade performance..

Then you may want to consider answering the question Nicholas asked, so
that he can provide more specific advice.

And for what it's worth, there's no such thing as "using kernel stuff"
_not_ in a thread. All code executes in a thread. You may only have a
single thread in which your code executes, but there's still a thread.

Pete

bbg wrote:

I am working on window service application in which threads come and go
and found ManualResetEvent was created but not used(nobody waiting).
So I became curious how creating unnecessary ManualResetEvent will affect
performance.

Well, IMHO the simplest way to find out is to test performance with and
without the object and see how it differs, if at all.

If all the code is doing is creating the event handle once and then not
doing anything with it, I doubt you'd notice any performance difference
at all.

About "using kernel stuff in thread is not good..",

http://msdn.microsoft.com/msdnmag/is...urrentAffairs/

I didn't see anything in that article that said "using kernel stuff in
thread is not good". If you think it does say that, perhaps you could
quote the exact passage, so that we know exactly which part of the
article gave you that impression.

What I did see is a comment regarding the expense of creating a
ManualResetEvent. The author also says that using one is expensive, but
I'd disagree with that. At the very least, using an event handle isn't
anything like creating an event handle, in terms of performance cost.

Certainly using an event handle is more expensive than not using one.
But then, synchronization in general can be expensive. On the other
hand, getting the wrong results from your code is usually worse, so
programmers opt for "expensive" over "incorrect". :)

Also, I'd have to go back and check, but my recollection is that, as is
the case with many synchronization objects, as long as there's no
contention the use of the object is actually quite efficient. It's only
when multiple threads are trying to get at the object simultaneously
that it gets expensive. But again, that's exactly the scenario in which
you really need the object, so the cost is worthwhile.

He is correct that you would probably want to avoid creating and
destroying event handles over and over if you can. But that's not the
same as the question of whether having a single event handle existing in
the thread would hurt performance, which is the question you seem to be
asking.

Pete

bbg wrote:

I am working on window service application in which threads come and go
and found ManualResetEvent was created but not used(nobody waiting).
So I became curious how creating unnecessary ManualResetEvent will affect
performance.

About "using kernel stuff in thread is not good..",

http://msdn.microsoft.com/msdnmag/is...urrentAffairs/

By the way, I went ahead and downloaded the code from that article so I
could try it myself. Unfortunately, Richter doesn't actually state the
specific results he got, however I was unable to reproduce a significant
difference in performance.

In fact, with the exact code available for download, while his
implementation is in fact faster for a task that doesn't actually do
anything, the built-in CLR implementation of the async processing is
_faster_ than his "don't create the event handle" version when the task
actually takes some time to complete.

On my PC, in the 0-time case for 100,000 task iterations, I get about
1.4 seconds for his implementation and 4.4 seconds for the CLR
implementation. His wins that round.

But when I change it so that the task length is 1 second, reducing the
iterations to 1000 (otherwise it takes too long to complete the test :)
), his version takes 47 seconds while the CLR takes only 40 seconds.

If I do 1000 iterations of 100 ms-long tasks (this required changing his
LongTask class so that I could initialize it using a TimeSpan instead of
with seconds, of course), then his implementation takes about 10.3
seconds while the CLR only takes 4.3 seconds.

Out of three different scenarios, his implementation wins only one,
while the CLR wins the other two. I suspect the CLR would win _any_
scenario in which the task thread doesn't complete immediately.

This is on a Core 2 Duo, 2.33Ghz computer running with Windows XP SP 2
and .NET 2.0.

As much as I respect what Richter writes elsewhere, I don't see any
strong evidence here that creating an event handle really impedes
performance. It seems to me that he hasn't really measured performance
in an interesting or useful way.

Even if creating an event handle does have some significant overhead
(and IMHO that's far from proven by the code for that article), whatever
difference exists is easily swamped by other performance differences
elsewhere in the code (for example, the context switching forced by
making the task threads block...and IMHO if you've got something that
costs less than a context switch, it's probably not worth worrying about
unless you've got a task that can complete in a single timeslice).

Pete

In my application, using his AsyncResultNoResult in some tasks - communicate
with database, create socket connection - resulted in about 30% speep up
compared to using BeginInvoke. The performance difference was not that big as
that of his example code but it was still fairly better than CLR. Can you
tell me what test you did?

Bob

"Peter Duniho" wrote:

bbg wrote:

I am working on window service application in which threads come and go
and found ManualResetEvent was created but not used(nobody waiting).
So I became curious how creating unnecessary ManualResetEvent will affect
performance.

About "using kernel stuff in thread is not good..",

http://msdn.microsoft.com/msdnmag/is...urrentAffairs/

By the way, I went ahead and downloaded the code from that article so I
could try it myself. Unfortunately, Richter doesn't actually state the
specific results he got, however I was unable to reproduce a significant
difference in performance.

In fact, with the exact code available for download, while his
implementation is in fact faster for a task that doesn't actually do
anything, the built-in CLR implementation of the async processing is
_faster_ than his "don't create the event handle" version when the task
actually takes some time to complete.

On my PC, in the 0-time case for 100,000 task iterations, I get about
1.4 seconds for his implementation and 4.4 seconds for the CLR
implementation. His wins that round.

But when I change it so that the task length is 1 second, reducing the
iterations to 1000 (otherwise it takes too long to complete the test :)
), his version takes 47 seconds while the CLR takes only 40 seconds.

If I do 1000 iterations of 100 ms-long tasks (this required changing his
LongTask class so that I could initialize it using a TimeSpan instead of
with seconds, of course), then his implementation takes about 10.3
seconds while the CLR only takes 4.3 seconds.

Out of three different scenarios, his implementation wins only one,
while the CLR wins the other two. I suspect the CLR would win _any_
scenario in which the task thread doesn't complete immediately.

This is on a Core 2 Duo, 2.33Ghz computer running with Windows XP SP 2
and .NET 2.0.

As much as I respect what Richter writes elsewhere, I don't see any
strong evidence here that creating an event handle really impedes
performance. It seems to me that he hasn't really measured performance
in an interesting or useful way.

Even if creating an event handle does have some significant overhead
(and IMHO that's far from proven by the code for that article), whatever
difference exists is easily swamped by other performance differences
elsewhere in the code (for example, the context switching forced by
making the task threads block...and IMHO if you've got something that
costs less than a context switch, it's probably not worth worrying about
unless you've got a task that can complete in a single timeslice).

Pete

bbg wrote:

In my application, using his AsyncResultNoResult in some tasks - communicate
with database, create socket connection - resulted in about 30% speep up
compared to using BeginInvoke. The performance difference was not that big as
that of his example code but it was still fairly better than CLR. Can you
tell me what test you did?

I don't understand your question. As I said, I simply downloaded the
code he published, compiled it and ran it.

For one of the tests I had to modify the class slightly so that I could
specify an under-one-second task duration, and of course for the two
tasks where the task has a non-zero duration I changed the iteration
count so that the test would complete in a reasonable amount of time.

I did not even bother to remove the functional test from his sample; I
didn't do anything that would affect it, but I just let it run anyway.

Basically, I changed nothing except the specific iteration count and
task duration used in the test. Otherwise, the code I ran was identical
to the code provided with the article.

Pete