Re: NSThread to NSOperation and blockUntil

[Graham Cox]

> On 22 Mar 2016, at 5:33 PM, Trygve Inda  wrote:
> 
> So I need to be able to have a process done in 30 seconds for example At
> full speed it could be done in 4 seconds but I'd like it done with as little
> impact as possible.


So just let it run as fast as possible. The whole point of threads is to let 
them work as hard as they need to and the scheduler will take care of giving 
other stuff the time they need. If the work is self-contained, in that it isn’t 
blocking other code, you won’t even notice it. It sounds like you’re trying to 
optimise based on faulty reasoning.

—Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread to NSOperation and blockUntil

[Jens Alfke]

> On Mar 22, 2016, at 2:33 AM, Trygve Inda  wrote:
> 
> So I need to be able to have a process done in 30 seconds for example At
> full speed it could be done in 4 seconds but I'd like it done with as little
> impact as possible.

I don’t think it makes much difference to other system threads whether your 
thread takes 4 seconds or 30 to complete. Modern computers are almost never 
starved for CPU resources since they have a lot of cores and the OS is very 
good at fast context switching. On my MBP the only time the CPU meter fills up 
all the way is when Xcode is doing a clean build of a project, and even then I 
don’t notice other apps slowing down.

If you’re really worried, you can use that background quality-of-service level 
on your thread/queue, and the OS will just put your thread on ice while other 
threads are contending for all the CPU cores.

The resources that are more often limited are RAM and I/O. So it makes _much_ 
more of a difference to the rest of the system if your task uses a lot of 
memory or reads/writes a lot of data. In that case it could be advantageous to 
slow it down artificially, although you might get more bang for the buck by 
trying to optimize the algorithms to use less memory or I/O.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSThread to NSOperation and blockUntil

[Quincey Morris]

On Mar 21, 2016, at 18:07 , Trygve Inda  wrote:
> 
> I would like to move this to NSOperation and NSOperationQueue but I see no
> way to replicate this behavior.

I think the GCD/NSOperationQueue concept of “background” quality of service is 
what you want here. That would let your re-factored calculations run at full 
speed during system idle times, using multiple CPUs, until CPU resources were 
needed for something of higher quality service. At that time, your background 
calculation would be throttled back until the system goes idle again.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSThread to NSOperation and blockUntil

[Trygve Inda]

I have a thread that is invoked with:

[NSThread detachNewThreadSelector:@selector(threadMethod:) toTarget:self
withObject:self];

It uses NSConditionLock and works well.

This thread performs a complex process but does it slowly so as to not use
much processor time. I specify how long I want it to take (1 to 30 minutes)
and use:

//  block this task until time has elapsed or an exit signal is received.
if ([[self lock] lockWhenCondition:kConditionThreadMustExit beforeDate:[self
blockUntil]])  
 [[self lock] unlock];

blockUntil simply checks to see how much work has been done vs how much time
has passed and if 50% of the work has been done, blocks until 50% of the
time has passed. It works well since the work is very linear.

I would like to move this to NSOperation and NSOperationQueue but I see no
way to replicate this behavior. My current thread is limited to a single
processor core and with NSOperation I could split it to multiple cores, but
in so doing I seem to lose this "delay for a while" bit.

Any ideas?

Thanks.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com