4 replies to this topic

[topgun_879]

Hi everyone,

I need some info on the Thread.Sleep() method. Would really appreciate anyone care to provide insights.

I scheduled my thread to sleep(1000), that is 1 second. But when it reports, the time varies like (hh:mm:ss:ff): 00:00:01:35, 00:00:02:85, 00:00:04:05. If you may have noticed, the 3rd second overlapped with increase in ff each time.

1. how many millisecond does it take to kick-start a sleeping thread?

2. What are those factors has direct or indirect effect when this sleeping thread wakes?

Rgds,
topgun

[farrell2k]

It depends on what the clr is doing. It could be collecting garbage. Another thread could have been preempted before your awoke Who knows.

[wim DC]

A processor can only process 1 thread/process at a time. To make it look like it's multitasking it's constantly switching threads and processes so they all appeir to run at the same time.

There are many processes waiting to be run. They are waiting in the so called "thread pool". The processor has to choose 1 and run it for a specific amount of time. Which process is taken and how long it will run is determined by the OS.
So dependant on wether the processor is very busy right now and there are other threads with a higher priority the time your sleeping thread willl awake will differ.

I think you're best of to remember the time right before you go to sleep. And measure the time again when you wake up. Use the size of the difference between the 2 to change variables a little bit.

[Syne]

That is generally true on single core and single processor architectures. Multi core processors, or multi-processor architectures are capable of performing simultaneous calculations to some degree. While multi-core processors still suffer from having the same cache, thus restricting their multi-processing capability, it is still very much possible, as you probably know, to execute two threads simultaneously.

There are also some hardware mechanisms, such as Hyperthreading, which allow for 'virtual multi-processing', which can be viewed as true multi-processing on some level. They are definitely not the same as OS-driven time splicing.

At any rate, the time it takes to make a thread sleep or for it to waken is generally pretty short. I've just tested it on my computer, and the discrepancy is fairly insignificant, and a large part of it might be the discrepancy in the DateTime class, at that, or the delay caused by method calls. Maybe you're not measuring the time properly? use GetTickCount to get the best results, and subtract one tick count from the other.

As for the factors, well, as you probably expect, they are numerous and rather extremely difficult to take into consideration. If your system is under stress, the thread might indeed take more than its allotted time to awaken, perhaps much more. You should never trust threads in general, in fact. They are bastards who will stab you in the back and dead/live/Schrodinger lock without remorse. You should use things like EventWaitHandle or lock to control your threads, rather relying on something like Sleep.

[topgun_879]

Hi guys,

Thank you so much for the info. I have really leant alot during this time investigation on threads on .NET. Thanks oxano for the variable adustment technique. But the pre-determined result is not consistent as on n cycles. Initially this helps in assuming to the nearest time but not accurate as in real-time system. Syne, i think it shoudl be ticks instead, yup u r right abt that. And i agree with you, they r really bastards..can reli stab us sometimes.. :) Thanks alot guys for the post. I would encourge more if there is anything can be added to the knowledge of this subject.

topgun,