Thread Start Delay

  • Thread starter Thread starter ales
  • Start date Start date
A

ales

Hello,

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());
}

Thanks for any advice.
 
ales,

There is always going to be some overhead in starting up a thread. The
only way I can think of around this would be to create a task in the
ThreadPool which will start up the thread for you.

You might want to run some tests to determine how long that takes.

Hope this helps.
 
Thank you for answer, Nicholas. It could be solution, but I don't agree
there has to be one second overhead when there is nothing else
hapenning in the system. Something has to be wrong.
 
ales,
You either have more code going on that you haven't shown us, or there's
definitely something wrong. That if block should not be trigggered under the
conditions you describe. It just doesn't take that long to kick off a thread.

What is the method in the ellipses?

Thread t = new Thread(...);

?

Peter
 
ales said:
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());
}

Thanks for any advice.
Click to expand...

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

Starting threads should generally be *fairly* fast. Not the kind of
thing you want to do thousands of times in quick succession, but not
something that takes nearly a second unless you've got a *very* heavily
loaded system.
 
Peter,
the method is private method of object A, which is invoked by the new
thread in 0 - 1 second after Thread.Start() - and this is my second
problem.
Could this be caused by locks on object A?
 
This is problem, it is a very complicated software and I'm not able to
simulate such behavior on small piece of code.
 
The way you are measuring a start dely is badly wrong, the resolution of the
system clock is something like 10 msec or more.



| Hello,
|
| 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());
| }
|
| Thanks for any advice.
|

The way you are measuring a start delay is badly wrong, the resolution of
the system clock is something like 10 msec or more. That means it's not
possible to measure this delay the way you are doing, nor does it make
sense. The time taken by the system to start a thread can vary from a few
hundred µsecs. to a few seconds or more, all depends on the CPU speed, #of
CPU's the current system activity, current threads activity and priority
etc...
If you need fast start of a thread procedure, your only option is to use the
threadpool or a private threadpool.

Willy.
 
ales said:
This is problem, it is a very complicated software and I'm not able to
simulate such behavior on small piece of code.
Click to expand...

Then I suspect the problem isn't actually anything to do with starting
the thread.
 
| Peter,
| the method is private method of object A, which is invoked by the new
| thread in 0 - 1 second after Thread.Start() - and this is my second
| problem.
| Could this be caused by locks on object A?
|

No, a lock would not prevent a thread from "starting, it can only prevent
the start of the thread procedure.

Willy.
 
Jon - Yes, I think so. But reality is the thread doesn't start. There
has to be something I haven't found in last few days in which I'm
trying to figure it out.
 
ales said:
Jon - Yes, I think so. But reality is the thread doesn't start. There
has to be something I haven't found in last few days in which I'm
trying to figure it out.
Click to expand...

Possibly, but without any more information we're not going to be able
to help you. You really need to try to work towards a short but
complete program which demonstrates the problem. Take a fresh copy of
your system and then cut things out of it until you can't cut anything
more without the problem going away.
 
| Willy - I cannot use threadpool because I need to be able to abort
| queued thread.
|

What do you mean with queued thread? Is this a running thread or is it a
work item scheduled to run on a thread?
Note that asynchronously aborting a running thread is realy bad, something
you should only consider when you are going to unload this thread's
application domain.

Willy.
 
| Jon - Yes, I think so. But reality is the thread doesn't start. There
| has to be something I haven't found in last few days in which I'm
| trying to figure it out.
|

Ok, this is getting confusing, is the thread (delayed) starting or isn't he
not starting at all?

Willy.
 
Yes, I meant work item scheduled to run on thread.
You are right, I'm now using thread.Abort() and should redesign the
application. Probably it is the time to do it now.
Sorry, I've written it doesn't start and meant doesn't start
immediatelly.
 
| Yes, I meant work item scheduled to run on thread.
| You are right, I'm now using thread.Abort() and should redesign the
| application. Probably it is the time to do it now.
| Sorry, I've written it doesn't start and meant doesn't start
| immediatelly.
|

Ok, but I told you in another answer that you should more precisely define
"immediately", threads need time to get created but it should not take more
than a couple of milliseconds to start one on a well behaving non overloaded
system.
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.

Willy.
 
Immediately is for me 10, 20ms. Anything above 100 ms second is not
acceptable.
I do not need absolutely accurate measurement, but thank you for info,
it may be used for some future measurement.
I will try to think a bit about the design, maybe will find some
another solution, hopefuly with minimum threads and without
thread.Abort()
Thank you for your advice
 
| Immediately is for me 10, 20ms. Anything above 100 ms second is not
| acceptable.
| I do not need absolutely accurate measurement, but thank you for info,
| it may be used for some future measurement.
| I will try to think a bit about the design, maybe will find some
| another solution, hopefuly with minimum threads and without
| thread.Abort()
| Thank you for your advice
|

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.

Willy.
 
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.
Click to expand...

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.)
 
Back
Top