Thread Start Delay

[Nick Hounsome]

You are not measuring the time to start a new thread.

What you are measuring is the time between calls to DateTime.Now. When you
call Start you may cause a context switch to one or more other threads - a
POSSIBLE sequence is this:

thread 1: calls Start
new thread: does stuff
thread 2: does stuff
....
thread n: does stuff
thread 1: calls DateTime.Now

The system is allowed to pick a new thread to run whenever a thread becomes
runnable and Start makes the new thread runnable.

Runnable threads at the same priority will be executed in a round robin
fashion so if all the threads are runnable the system can put thread 1 to
the end of the queue behind all the others when it executes Start.

Even DateTime.Now COULD be a scheduling point depending on exactly how the
time is obtained.

 

[Willy Denoyette [MVP]]

|
| <snip>
|
| > Notice that I said that the way you measure is flawed, you should use
the
| > resolution timer (Stopwatch in v2 or QueryPerformanceCounter through
PInvoke
| > in v1)to measure such delays.
|
| It's only flawed if you need to get a very exact measurement. To be
| honest, I don't find QueryPerformanceCounter to be worth the effort in
| 1.1 - if I'm trying to time something, I almost never care about that
| level of detail, as you need to get a longer period of time in order to
| reduce the effect of the "noise" of the system anyway. So for a
| benchmark, I try to get times of a few seconds or more, at which point
| 10ms either way isn't particularly significant.
|
| (I use Stopwatch in 2.0 sometimes because it's just as easy to do that
| as not to.)

Agreed, but this is not a benchmark. here the OP 'thinks' he needs to
measure the time it takes to start a thread in a real application, well, the
way he does is flawed so the result has little or no value. Note that
benchmarking thread starts by spawning threads for a longer period have
little value either, the results obtained are mostly "best case" and they
should not be used to answer the question "do I spawn new threads in
succession or do I use a pool of threads". There are other, more important
costs than 'start times' to consider when using threads.

Willy.

 

[Jon Skeet [C# MVP]]

| It's only flawed if you need to get a very exact measurement. To be
| honest, I don't find QueryPerformanceCounter to be worth the effort in
| 1.1 - if I'm trying to time something, I almost never care about that
| level of detail, as you need to get a longer period of time in order to
| reduce the effect of the "noise" of the system anyway. So for a
| benchmark, I try to get times of a few seconds or more, at which point
| 10ms either way isn't particularly significant.
|
| (I use Stopwatch in 2.0 sometimes because it's just as easy to do that
| as not to.)

Agreed, but this is not a benchmark. here the OP 'thinks' he needs to
measure the time it takes to start a thread in a real application, well, the
way he does is flawed so the result has little or no value.

I disagree. I suspect it's only a problem for him if it takes a fair
amount of time, eg 10ms. In fact, I suspect that it must be taking
longer than that for it to have been noticed in the first place.

Note that benchmarking thread starts by spawning threads for a longer period have
little value either, the results obtained are mostly "best case" and they
should not be used to answer the question "do I spawn new threads in
succession or do I use a pool of threads". There are other, more important
costs than 'start times' to consider when using threads.

I certainly agree with that, but I don't think it invalidates the
coarse test of "is this where my problem is" by using DateTime.Now. For
1.1 projects, that's considerably simpler than using performance
counters, and is often all that's needed.

Jon

 

[Willy Denoyette [MVP]]

| Willy Denoyette [MVP] wrote:
| > | It's only flawed if you need to get a very exact measurement. To be
| > | honest, I don't find QueryPerformanceCounter to be worth the effort in
| > | 1.1 - if I'm trying to time something, I almost never care about that
| > | level of detail, as you need to get a longer period of time in order
to
| > | reduce the effect of the "noise" of the system anyway. So for a
| > | benchmark, I try to get times of a few seconds or more, at which point
| > | 10ms either way isn't particularly significant.
| > |
| > | (I use Stopwatch in 2.0 sometimes because it's just as easy to do that
| > | as not to.)
| >
| > Agreed, but this is not a benchmark. here the OP 'thinks' he needs to
| > measure the time it takes to start a thread in a real application, well,
the
| > way he does is flawed so the result has little or no value.
|
| I disagree. I suspect it's only a problem for him if it takes a fair
| amount of time, eg 10ms. In fact, I suspect that it must be taking
| longer than that for it to have been noticed in the first place.
|

Well, it looks like only the OP can answer that question, maybe he did
notice something but IMO it has nothing to do with a thread "start delay",
read one of it's other replies that asks about a lock on his thread
procedure, IMO he noticed a (variable?) delay when executing the thread
proc, but thinks it's due to the thread start delay.

Anyway there are far better ways to measure such intervals (if you ever need
to), using a timer with a 10-20 msec. resolution to measure possible
millisecond or even sub-milliseconds intervals makes no sense, unless you
know that a result of 0 could also mean 15 msecs. and 16 msec. could also be
30 msec.


| > Note that benchmarking thread starts by spawning threads for a longer
period have
| > little value either, the results obtained are mostly "best case" and
they
| > should not be used to answer the question "do I spawn new threads in
| > succession or do I use a pool of threads". There are other, more
important
| > costs than 'start times' to consider when using threads.
|
| I certainly agree with that, but I don't think it invalidates the
| coarse test of "is this where my problem is" by using DateTime.Now. For
| 1.1 projects, that's considerably simpler than using performance
| counters, and is often all that's needed.
|

Who said performance counters? I'm talking about a Win32 API call
QueryPerformanceCounter(...), all you need is a two PInvoke declarations
wrapped in a utility class and you are done, just like Stopwatch does,
right?.
Even if you don't wan't to do all this you can :

start a utility like (but not restricted to) dbgvw.exe (from
www.sysinternals.com)
change your code like this:
Debug.WriteLine("start")
t.Start();
Debug.WriteLine("started")
and oeps instant accurate (in terms of whats possible on NT like systems).

Willy.

 

[Jon Skeet [C# MVP]]

| I disagree. I suspect it's only a problem for him if it takes a fair
| amount of time, eg 10ms. In fact, I suspect that it must be taking
| longer than that for it to have been noticed in the first place.

Well, it looks like only the OP can answer that question, maybe he did
notice something but IMO it has nothing to do with a thread "start delay",
read one of it's other replies that asks about a lock on his thread
procedure, IMO he noticed a (variable?) delay when executing the thread
proc, but thinks it's due to the thread start delay.

Ironically, the OP has answered the question of what accuracy he wants:
"Immediately is for me 10, 20ms. Anything above 100 ms second is not
acceptable."

In other words, using DateTime.Now is more than adequate to tell the
difference between acceptable and unacceptable.

Anyway there are far better ways to measure such intervals (if you ever need
to), using a timer with a 10-20 msec. resolution to measure possible
millisecond or even sub-milliseconds intervals makes no sense, unless you
know that a result of 0 could also mean 15 msecs. and 16 msec. could also be
30 msec.

And if you need to measure those intervals, I agree. I just don't think
that such a level of accuracy is called for in this case.

| I certainly agree with that, but I don't think it invalidates the
| coarse test of "is this where my problem is" by using DateTime.Now. For
| 1.1 projects, that's considerably simpler than using performance
| counters, and is often all that's needed.

Who said performance counters? I'm talking about a Win32 API call
QueryPerformanceCounter(...),

I couldn't remember the exact name of the API call, but knew it was
*something* like the above. It's not entirely unreasonable to think
that a call to "QueryPerformanceCounter" has something to do with
performance counters

all you need is a two PInvoke declarations
wrapped in a utility class and you are done, just like Stopwatch does,
right?.

So do you have that utility class handy in every piece of code you
write? Or do you need to always add a reference to a project that
contains it? I'd rather not do that unless I really need to - and I see
no evidence for that need in this case.

Even if you don't wan't to do all this you can :

start a utility like (but not restricted to) dbgvw.exe (from
www.sysinternals.com)
change your code like this:
Debug.WriteLine("start")
t.Start();
Debug.WriteLine("started")
and oeps instant accurate (in terms of whats possible on NT like systems).

Again though, it's more hassle than using DateTime.Now if accuracy like
that isn't required.

Jon

 

[Willy Denoyette [MVP]]

| >> I have a problem with creation of new thread. The method .Start() of
| >> newly created thread delays current thread for 0 - 1 second.
| >> Cpu while delay occurs is about 5%.
| >>
| >> Any idea?
| >>
| >> Here is code used for measuring:
| >>
| >> Thread t = new Thread(...);
| >> DateTime dttt = DateTime.Now;
| >> t.Start();
| >> TimeSpan ts = DateTime.Now - dttt;
| >> if (ts > new TimeSpan(0, 0, 0, 0, 20))
| >> {
| >> LogToScreen("!!!Thread Start Duration : " + ts.ToString());
| >> }
|
| You are not measuring the time to start a new thread.
|
| What you are measuring is the time between calls to DateTime.Now. When you
| call Start you may cause a context switch to one or more other threads - a
| POSSIBLE sequence is this:
|
| thread 1: calls Start
| new thread: does stuff
| thread 2: does stuff
| ...
| thread n: does stuff
| thread 1: calls DateTime.Now
|
| The system is allowed to pick a new thread to run whenever a thread
becomes
| runnable and Start makes the new thread runnable.
|
| Runnable threads at the same priority will be executed in a round robin
| fashion so if all the threads are runnable the system can put thread 1 to
| the end of the queue behind all the others when it executes Start.
|
| Even DateTime.Now COULD be a scheduling point depending on exactly how the
| time is obtained.
|
|

Exactly, what the OP is measuring is not the time it takes to start a
thread, it's the time his thread is off CPU. Or the interval between two
thread switches, one to start the OS thread and another switch when his
thread gets scheduled again. What happens in between is just a matter of
system activity, if you happen to have a single long running high priority
thread in the system it can take seconds to get the CPU back for your
thread.

Willy.

 

[Guest]

I think Jon has given you the best advice. I would start with the simplest
example of your threaded application that you can, and add functionality
until it breaks.

The key to troubleshooting a complex problem that you can't debug is to just
divide and conquer. Use Visual Source Safe so you can roll back, then add
functionality in medium sized blocks. When you break the application, roll
back to the last working version, and then start adding code in smaller
blocks. You're basically doing a successive approximation of your code to
break it down.

 

[Willy Denoyette [MVP]]

| Willy Denoyette [MVP] wrote:
| > | I disagree. I suspect it's only a problem for him if it takes a fair
| > | amount of time, eg 10ms. In fact, I suspect that it must be taking
| > | longer than that for it to have been noticed in the first place.
| >
| > Well, it looks like only the OP can answer that question, maybe he did
| > notice something but IMO it has nothing to do with a thread "start
delay",
| > read one of it's other replies that asks about a lock on his thread
| > procedure, IMO he noticed a (variable?) delay when executing the thread
| > proc, but thinks it's due to the thread start delay.
|
| Ironically, the OP has answered the question of what accuracy he wants:
| "Immediately is for me 10, 20ms. Anything above 100 ms second is not
| acceptable."
|

Yes, but that was AFTER I told him his way of measuring was flawed, he never
said what exactly he measured not what he was expecting before that. If you
measure something that normally takes a from ~500 µseconds up to a few 10
milliseconds you shouldn't use a timer with a resolution of 10 - 20 msecs.


| In other words, using DateTime.Now is more than adequate to tell the
| difference between acceptable and unacceptable.
|
| > Anyway there are far better ways to measure such intervals (if you ever
need
| > to), using a timer with a 10-20 msec. resolution to measure possible
| > millisecond or even sub-milliseconds intervals makes no sense, unless
you
| > know that a result of 0 could also mean 15 msecs. and 16 msec. could
also be
| > 30 msec.
|
| And if you need to measure those intervals, I agree. I just don't think
| that such a level of accuracy is called for in this case.
|

Again, he only mentioned his requirements after I asked for, besides, what's
wrong with a higher level of accuracy, does it hurt?.

| > | I certainly agree with that, but I don't think it invalidates the
| > | coarse test of "is this where my problem is" by using DateTime.Now.
For
| > | 1.1 projects, that's considerably simpler than using performance
| > | counters, and is often all that's needed.
| >
| > Who said performance counters? I'm talking about a Win32 API call
| > QueryPerformanceCounter(...),
|
| I couldn't remember the exact name of the API call, but knew it was
| *something* like the above. It's not entirely unreasonable to think
| that a call to "QueryPerformanceCounter" has something to do with
| performance counters
|

Actually, it's a call into Kernel32.dll a system library, it's the same API
is used by the performance counters and now Stopwatch but not the other way
around.


| > all you need is a two PInvoke declarations
| > wrapped in a utility class and you are done, just like Stopwatch does,
| > right?.
|
| So do you have that utility class handy in every piece of code you
| write? Or do you need to always add a reference to a project that
| contains it? I'd rather not do that unless I really need to - and I see
| no evidence for that need in this case.
|

I don't. I have more accurate tools available if really needed, tools that
count the # of CPU instructions executed between two trigger points for
instance, I rarely feel the need to measure such delays though when running
managed code.
However, other people may find such a library of tools usefull, IMO it's one
of the reasons MS has added Stopwatch to the framework, just to prevent
people to re-invent the wheel.


| > Even if you don't wan't to do all this you can :
| >
| > start a utility like (but not restricted to) dbgvw.exe (from
| > www.sysinternals.com)
| > change your code like this:
| > Debug.WriteLine("start")
| > t.Start();
| > Debug.WriteLine("started")
| > and oeps instant accurate (in terms of whats possible on NT like
systems).
|
| Again though, it's more hassle than using DateTime.Now if accuracy like
| that isn't required.
|

Oh come on, where's the hassle ? Start the debug viewer?
What's the difference between calling

DateTime start = DateTime.Now;
...
Console.WriteLine("{0}", TimeSpan(.....));

vs.
Debug.Write("...")
....
Debug.Write("...")

Agreed, when precision is not an issue, you can do with DateTime.Now, but if
you really need to measure things that will take less than a few hundred
milliseconds there are better ways like Stopwatch in v2 and
QueryPerformanceXXXX in v1.

Willy.

 

[Jon Skeet [C# MVP]]

| Ironically, the OP has answered the question of what accuracy he wants:
| "Immediately is for me 10, 20ms. Anything above 100 ms second is not
| acceptable."

Yes, but that was AFTER I told him his way of measuring was flawed, he never
said what exactly he measured not what he was expecting before that. If you
measure something that normally takes a from ~500 µseconds up to a few 10
milliseconds you shouldn't use a timer with a resolution of 10 - 20 msecs.

Certainly. I wasn't arguing that you should have been prescient - you
just seemed to still regard it as the wrong way of doing things despite
the answer given. Apologies if I've read too much into what you've
written.

| And if you need to measure those intervals, I agree. I just don't think
| that such a level of accuracy is called for in this case.

Again, he only mentioned his requirements after I asked for, besides, what's
wrong with a higher level of accuracy, does it hurt?.

Yes, if it takes longer to do, adding PInvoke calls or downloading an
extra tool. Using Stopwatch is a different kettle of fish, of course.

| So do you have that utility class handy in every piece of code you
| write? Or do you need to always add a reference to a project that
| contains it? I'd rather not do that unless I really need to - and I see
| no evidence for that need in this case.

I don't. I have more accurate tools available if really needed, tools that
count the # of CPU instructions executed between two trigger points for
instance, I rarely feel the need to measure such delays though when running
managed code.
However, other people may find such a library of tools usefull, IMO it's one
of the reasons MS has added Stopwatch to the framework, just to prevent
people to re-invent the wheel.

Absolutely - and it's great that they have. However, when working with
1.1, if I don't really need a wheel, I don't think it's worth
reinventing it

| Again though, it's more hassle than using DateTime.Now if accuracy like
| that isn't required.

Oh come on, where's the hassle ? Start the debug viewer?

Yes - discover the existence of it, download it (and tell all your
colleagues about it), then start it when you need it. It may not be
*very* much hassle, but it's more hassle than not doing it in the first
place.

Agreed, when precision is not an issue, you can do with DateTime.Now, butif
you really need to measure things that will take less than a few hundred
milliseconds there are better ways like Stopwatch in v2 and
QueryPerformanceXXXX in v1.

We certainly agree that if you need *accurate* timing it's worth using
those, and in 2.0 I'd suggest using Stopwatch anyway. Under 1.1 though,
I'd only go for the other techniques when I really needed the
precision. It's not just that you *can* do it, but that it's *simpler*
to do it unless you already happen to have everything available.

Jon

 

[Willy Denoyette [MVP]]

See inline

**** Willy

| Ironically, the OP has answered the question of what accuracy he wants:
| "Immediately is for me 10, 20ms. Anything above 100 ms second is not
| acceptable."

Yes, but that was AFTER I told him his way of measuring was flawed, he
never
said what exactly he measured not what he was expecting before that. If
you
measure something that normally takes a from ~500 µseconds up to a few 10
milliseconds you shouldn't use a timer with a resolution of 10 - 20 msecs.

Certainly. I wasn't arguing that you should have been prescient - you
just seemed to still regard it as the wrong way of doing things despite
the answer given. Apologies if I've read too much into what you've
written.

| And if you need to measure those intervals, I agree. I just don't think
| that such a level of accuracy is called for in this case.

Again, he only mentioned his requirements after I asked for, besides,
what's
wrong with a higher level of accuracy, does it hurt?.

Yes, if it takes longer to do, adding PInvoke calls or downloading an
extra tool. Using Stopwatch is a different kettle of fish, of course.

**** Willy
The extra tools have to be downloaded once and is something which is good to
have in your developers toolset anyway, just like a bunch of other
diagnostic tools from the same authors or others (see later).

As far as the API call goes, it's not more than a couple of source code
lines, wrap it in a class and drop it in a library, you can start using it
when appropriate and you can remove it when it's covered by the framework,
don't you have a small private library with some utility classes in your
toolset? I'm almost sure you do!
Really, there is a lot more missing in the framework that has to be done by
calling API's, the V1 framework doesn't cover half of what I need (the
windows security stuff is completely missing), jeez, you can't impersonate a
user without a call to LogonUser() even not in V2. You know why?
*****

| So do you have that utility class handy in every piece of code you
| write? Or do you need to always add a reference to a project that
| contains it? I'd rather not do that unless I really need to - and I see
| no evidence for that need in this case.

I don't. I have more accurate tools available if really needed, tools that
count the # of CPU instructions executed between two trigger points for
instance, I rarely feel the need to measure such delays though when
running
managed code.
However, other people may find such a library of tools usefull, IMO it's
one
of the reasons MS has added Stopwatch to the framework, just to prevent
people to re-invent the wheel.

Absolutely - and it's great that they have. However, when working with
1.1, if I don't really need a wheel, I don't think it's worth
reinventing it

*** Willy
You don't have to re-invent, if you don't wan't to use the Debug.Trace or
Debug.Write call, the output goes to a debug viewer or to the systems
supplied trace viewer (tracelog.exe), it's just a matter of knowing your
tools really.
***

| Again though, it's more hassle than using DateTime.Now if accuracy like
| that isn't required.

Oh come on, where's the hassle ? Start the debug viewer?

Yes - discover the existence of it, download it (and tell all your
colleagues about it), then start it when you need it. It may not be
*very* much hassle, but it's more hassle than not doing it in the first
place.

*** Willy
If you need to measure, be sure how and what to measure and use the right
tools, if you think DateTime.Now is the right thing for you, ok go for it,
I'm sure you know about the timer precison - and if it returns 20 msecs.
that it could be somethins between 1 and 20 msec, but are you sure all
others know this too? Sorry, but I'm not.
***

Agreed, when precision is not an issue, you can do with DateTime.Now, but
if
you really need to measure things that will take less than a few hundred
milliseconds there are better ways like Stopwatch in v2 and
QueryPerformanceXXXX in v1.

We certainly agree that if you need *accurate* timing it's worth using
those, and in 2.0 I'd suggest using Stopwatch anyway. Under 1.1 though,
I'd only go for the other techniques when I really needed the
precision. It's not just that you *can* do it, but that it's *simpler*
to do it unless you already happen to have everything available.

*** Willy
Again, you have the tools available, a serious developer has an MSDN
subscription (as you do) containing the SDK's and the system comes with a
bunch of tools. I know most aren't well known, they don't have a fancy UI,
but hey! they are developer tools, you only need to learn to use them, you
will be suprised of their power and 'ease' of use. No more silly discussion
like:

"I a have a memory leak",
how do you know?
"taskman told me so".
No, use vadump.exe or the kernel debugger, but please stop guessing where
your memory goes and who's to blame. If these tools are too complex, ok,
they require some expertise, but they are what you need to accurately trace
memmory and other leaks, no more guesswork. After some time you won't use
them that frequently, you can make some educated "guess" because you know
what really goes on.

The same goes for VS, some are quite happy with it's toolset it's debugger
and stuff, it has everything most people need and a pretty facade (well sort
of), but it's largely over-engineerd it's too heavy weight, (it looks like
Word) at least for me.

well I'm not and therefore I'm using other tools, not well integrated fancy
UI, most command line oriented, but much more efficient.
***

Willy.

 

[Jon Skeet [C# MVP]]

See inline

<snip>

I think we'll have to agree to differ. I don't have a single library
which is *always* around whatever project I'm working on (I couldn't
very easily, as I work on code for pleasure and commercially, and not
even all the commercial stuff has common references), and for the most
part I *am* content with the facilities provided by the VS debugger.
Not always - in particular it's sometimes handy to get cordbg out to
see what's getting inlined etc - but I try to avoid the debugger anyway
for the most part.

I'll keep using DateTime.Now when I don't need anything more accurate -
which I haven't done for a very long time.

 

[ales]

Willy:

Windows is not a real-time system, there are no strong guarantees to make
about process/thread creation times, neither about thread scheduling times.
A single thread that runs at high priority can prevent other threads to run,
the system has a mechanism to prevent starvation, but it's only after 5
seconds that the other run-able threads will get a chance to run for a
couple of quantum slices only. That's why I said on a well behaving system,
it should not take more than a few millisec's. to start a new thread, but
this is not guaranteed.

Ok, but the situation is the cpu is max 10% and there is nothing
hapenning for one second. Can you explain this? Why the new thread
doesn't start and existing thread is suspended?

 

[ales]

Dale - again, the application is too complex. I would spend a lot of
time by preparing it. And time is what prevents doing it.

 

[William Stacey [MVP]]

Why is there an existing thread? Could you not reuse that thread instead of
starting another one?
Also, add some debug messages with ms timespans in your start logic to try
to catch where your getting slow. It could be your waiting on a lock or
something in your thread. How many threads are you starting? Why not just
start a few worker threads that loop for work instead of creating new
threads?

--
William Stacey [MVP]

| Willy:
| >Windows is not a real-time system, there are no strong guarantees to make
| >about process/thread creation times, neither about thread scheduling
times.
| >A single thread that runs at high priority can prevent other threads to
run,
| >the system has a mechanism to prevent starvation, but it's only after 5
| >seconds that the other run-able threads will get a chance to run for a
| >couple of quantum slices only. That's why I said on a well behaving
system,
| >it should not take more than a few millisec's. to start a new thread, but
| >this is not guaranteed.
|
| Ok, but the situation is the cpu is max 10% and there is nothing
| hapenning for one second. Can you explain this? Why the new thread
| doesn't start and existing thread is suspended?
|

 

[Willy Denoyette [MVP]]

| Willy:
| >Windows is not a real-time system, there are no strong guarantees to make
| >about process/thread creation times, neither about thread scheduling
times.
| >A single thread that runs at high priority can prevent other threads to
run,
| >the system has a mechanism to prevent starvation, but it's only after 5
| >seconds that the other run-able threads will get a chance to run for a
| >couple of quantum slices only. That's why I said on a well behaving
system,
| >it should not take more than a few millisec's. to start a new thread, but
| >this is not guaranteed.
|
| Ok, but the situation is the cpu is max 10% and there is nothing
| hapenning for one second. Can you explain this? Why the new thread
| doesn't start and existing thread is suspended?
|

No, I can't. But what you should do is measure the interval between the
Thread.Start call and the moment you enter the thread procedure (well your
private method...), because this is the real start time.

DateTime dttt = DateTime.Now;
t.Start();


ThreadProcWhatever(...)
{
TimeSpan ts = DateTime.Now - dttt;
...

}

Willy.

 

[ales]

Why is there an existing thread? Could you not reuse that thread instead of
starting another one?

By existing thred is meant actual thread which starts new thread

Also, add some debug messages with ms timespans in your start logic to try
to catch where your getting slow. It could be your waiting on a lock or
something in your thread.

Yes, I added a lot of debug messages, but still nothing

How many threads are you starting?

At this point just one.

Why not just start a few worker threads that loop for work instead of creating new threads?

Yes, I will do it this way.

 

[ales]

No, I can't. But what you should do is measure the interval between the
Thread.Start call and the moment you enter the thread procedure (well your
private method...), because this is the real start time.

DateTime dttt = DateTime.Now;
t.Start();


ThreadProcWhatever(...)
{
TimeSpan ts = DateTime.Now - dttt;
...

Yes, this is second issue. This start time is from few millisedonds to
one second too. And it is the same for thread run either by new
Thread() or ThreadPool.QueueWorkItem().

 

[Willy Denoyette [MVP]]

| Willy Denoyette [MVP] wrote:
|
| > No, I can't. But what you should do is measure the interval between the
| > Thread.Start call and the moment you enter the thread procedure (well
your
| > private method...), because this is the real start time.
| >
| > DateTime dttt = DateTime.Now;
| > t.Start();
| >
| >
| > ThreadProcWhatever(...)
| > {
| > TimeSpan ts = DateTime.Now - dttt;
| > ...
|
| Yes, this is second issue. This start time is from few millisedonds to
| one second too. And it is the same for thread run either by new
| Thread() or ThreadPool.QueueWorkItem().
|

Well that means your CPU is busy with other threads, could be higher
priority or equal priority threads. Could be that there is a lot of IO
activity, while this doesn't generate a lot of CPU activity, it may well
wake up a thread or a number of threads very frequently and as these threads
have their priority boosted (after an IO) it might be the reason for the
delay's.

Willy.