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

Group
 
 

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

Submitter:  Brock Erwin <berwin>
Submitted:  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
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

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
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    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 -email is unavailable-

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code