Re: Accuracy of NSThread sleepUntilDate
Re: Accuracy of NSThread sleepUntilDate
- Subject: Re: Accuracy of NSThread sleepUntilDate
- From: Lloyd Sargent <email@hidden>
- Date: Fri, 3 Aug 2001 13:35:56 -0500
On Friday, August 3, 2001, at 11:30 AM, cocoa-dev-
email@hidden wrote:
From: Christian Mike <email@hidden>
To: "'Cocoa List'" <email@hidden>
Subject: Accuracy of NSThread sleepUntilDate
Date: Fri, 3 Aug 2001 08:03:06 -0500
I have a multithreaded application in which the threads will sometimes
delay
for a short time. I use the code:
NSTimeInterval timeInterval = (NSTimeInterval) someMilliseconds /
1000.0;
[NSThread sleepUntilDate:[NSDate
dateWithTimeIntervalSinceNow:timeInterval]];
Now I am not look for high accuracy here. I realize that when you give
up
the processor in a multithreaded application that all bets are off. I am
just looking for some ball park answer about how accurate this delay
mechanism is. What is a reasonably expected quantization unit here?
Is there some better way to put a thread to sleep for a short (10's of
milliseconds) time?
Thanks.
Michael Christian
Thomson multimedia Inc.
There is another way that is Cocoa-ey, but possibly not very pretty:
[NSThread sleepUntilDate:[[NSDate date] addTimeInterval:delay]];
There the delay is a double. So for example you could have the following:
[NSThread sleepUntilDate:[[NSDate date] addTimeInterval: 0.01]];
Now, mind you, it will cost you microseconds and bytes to do all of
this, but I've been using it in a serial comm. app without any
noticeable degradation.
Also have used the usleep() with success. Not sure what advantages one
has over the other. Anyone at Apple (or elsewhere) like to comment?
Cheers,
Lloyd
---
Canna Software Development
"This email was created using 100% recycled electrons"