timeslice question

[davidk2]

Hi all,

I think I know the answer to this bt there is no harm in asking a question !!



Is there anyway to stop my process from being timesliced out by any and all processes (Other than increasing its priority).

Thanks,

David

[mario]

You can disable interrupt on uni-processor machine, but that's cruel

You could send a stop signal to all processes, again that would be very cruel.

[juanplacco]

You aren't talking about FIFO scheduling policy, are you?

[davidk2]

Hi guys,

Thanks for the speedy response your guys are worth 10 times a QNX support contract .

It's not a uniprocessor machine so that option is out. I suppose I could send the stop signal to all processes but I think that may be a bit like cracking a nut with a sledgehammer although I should maybe do some experimentation with that idea (I only need to process for about 100 mSec or so but I HAVE to have it for that period).

Not really talking about priority, what I am talking about is disabling all scheduling for a very short period programmatically .

I think requiring this shows a bad design flaw in the driver. I may have to re-write the driver a bit so I do not require these 'hacks'.

Thanks again for the fast response.

[mario]

Why is rising the priority not an option? Remember that it could still get disrupted by interrupt.

When disabling interrupts they could be re-enabled at the first kernel call. On a non uniprocessor you can't guaranty that another process will not perform a kernel call. However I think you could Mask every single interrupt. You said you need to do this 100ms, it my opinion that's way too long to mask interrupt. I could have unforseen effect on other processes, like qnet timing out and breaking existing connection.

If you have a mean to get rid of that requirement, you should fix this problem at the source.

[Tim]

David,

Is that 100 milliseconds or 100 microseconds you need the CPU for?

Tim

[maschoen]

IF you are writing a driver, and IF the driver needs control over the processor without interruption for a SHORT period of time, then you can either turn off interrupts asm "cli" or is it "sti"? Doing this potentially adds to the real time latency which is why you should only turn off interrupts for a very short amount of time. If your code is in an interrupt handler, you only need to do this if you are worried about being interrupted by higher priority interrupts. If you are running in a thread and you are worried about being interrupted by your own interrupt handler, you can mask that interrupt line, which is kinder than turn off all interrupts.

[mario]

IF you are writing a driver, and IF the driver needs control over the processor without interruption for a SHORT period of time, then you can either turn off interrupts asm "cli" or is it "sti"?

With QNX6 and multi-core that's not a viable solution because if a process on another core does a kernel call the interrupt will be enabled.

[maschoen]

How unsporting.

[cburgess]

With QNX6 and multi-core that's not a viable solution because if a process on another core does a kernel call the interrupt will be enabled.

That's not true. The interrupt enable/disable is local to the processor, another cpu doing a kernel call is not going to affect your local interrupt status.

InterruptLock() is probably what you want to use, that combines and InterruptDisable with a spinlock.

[mario]

Ok.

If a thread disables interrupt while running on say process 2, is there anything that prevents it from be migrated to another processor then?

[cburgess]

If processor one decides to reschedule a thread, and it thinks processor 2 is the best fit, then it will send an IPI to processor 2, telling it to reschedule. If you have interrupts disabled, then it can't act on that,
until you re-enable them.

[mario]

Thanks for the explanation!

[tfletche]

Just out of curiosity .. why wouldn't you want to adjust its priority rather than taking the rather heavy handed interrupt approach?

Thomas

[maschoen]

Here's a guess, Let's say you are uh...mmmm, using a critical timing loop. Not much hardware I've worked with in the last 20 years needs such a thing but it is possible. Well even at high priority, you could get interrupted by a hardware interrupt.