bugGNUstep - Bugs: bug #28757, [NSThread sleepUntilDate:] in this...


You are not allowed to post comments on this tracker with your current authentication level.

bug #28757: [NSThread sleepUntilDate:] in this example uses 100% of a CPU while sleeping on MinGW

Submitted by:  Brock Erwin <berwin>
Submitted on:  Thu 28 Jan 2010 06:32:38 PM UTC  
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Wed 03 Feb 2010 09:47:06 AM UTC, comment #3: 

Found this ...
If the configure script detects the usleep() function, the code uses that (because it has microsecond granularity) rather than the Sleep() function (millisecond granularity).
Unfortunately, on windows usleep() performs a busy wait using the cpu.
I fixed this by changing the code so that, on windows, it  always uses Sleep() except for small intervals (under 0.1 sec) where we might reasonably need higher accuracy.

Richard Frith-Macdonald <CaS>
Project Member
Fri 29 Jan 2010 05:46:43 PM UTC, comment #2: 

Yes, it really does happen.

I looked at NSThread.m in the svn repository, and I agree with you that it seems to reduce to a simple Sleep() call, which should work correctly.  However, I did notice one interesting thing.  The MINGW32 code looks like this:

while (delay > 0)
    Sleep (delay*1000);
    delay = when - GSTimeNow();

If for some odd reason Sleep() returns early and doesn't sleep the "whole" time, then the delay would be recalculated and the loop would continue again.

What you proposed was to print out what value is being passed to Sleep() for each iteration, correct?  This would require me to recompile GNUstep on mingw (I believe).  I'm not sure I really want to do this.

Finally, it seems that anytime I try to call [NSThread sleepUntilDate:d]; where d is greater than 1 second in the future, it pegs one processor for 100% usage.  Anything less than 1 second in the future and that problem disappears.  In either case, the method doesn't return until the proper amount of time has passed, but CPU usage seems to be amiss in one of the cases.

Brock Erwin <berwin>
Fri 29 Jan 2010 02:59:53 PM UTC, comment #1: 

Please check that this really happens.

It doesn't use CPU for me ... but I don't have a quad core machine.

This reduces to a call of the windows Sleep() function (in NSThread.m) ... I can't see why that would use a lot of CPU (and I can't see how a bad argument could be being passed to it), but you could try adding a timestamped log of the argument before each Sleep() call to see what the issue is on your system.

Richard Frith-Macdonald <CaS>
Project Member
Thu 28 Jan 2010 06:32:38 PM UTC, original submission:  

I compiled the following code on a WindowsXP machine in a MinGW environment.  When I run the program, I notice that I have 25% CPU usage (I have a QUAD core machine), so that's 100% of one core.  You would expect it to use near 0% of the processor since it is sleeping most of the time. I had to tweak the time variable to notice this behavior, however, and when I set it to time = 10000, the CPU usage is around 0% as I would expect.

#import <Foundation/Foundation.h>
#include <stdio.h>
#include <Windows.h>
#include <fcntl.h>

int main(int argc, char argv[], char env[]) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

NSDate *d;
NSTimeInterval time;

//time = 10000; //  a long time
time = 10; // 10 seconds ?
while (YES) {

d=[NSDate dateWithTimeIntervalSinceNow: time];
[NSThread sleepUntilDate:d];

// [NSThread sleepForTimeInterval:1];

printf("one iteration\n");

[pool release];

Brock Erwin <berwin>


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by berwin (Submitted the item)
  • -email is unavailable- added by berwin

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-02-03 CaS StatusWorks For Me => Fixed
        Open/ClosedOpen => Closed
    2010-01-29 CaS StatusNone => Works For Me
    2010-01-28 berwin Carbon-Copy- => Added evan.felix@pnl.gov

    Back to the top

    Powered by Savane 3.5