Re: deferred cancellation of ipc

[Marcus Brinkmann]

On Tue, Oct 14, 2003 at 11:33:19AM -0700, Volkmar Uhlig wrote:
> The idea is to use delayed preemptions.  When you toggle the delayed
> preemption bit the kernel will not preempt the thread except it exceeds
> its grace period.  If that happens the kernel will trigger an exception
> and you can have some back off code dealing with that (implementation is
> up to you).  Delayed preemptions allow to implement _short_ atomic
> operations.  

I am not convinced for two reasons.  One is that this code should be
executed by untrusted tasks, and for those who want to disable preemption
for security reasons.  That can probably be amortized by setting a very
short preemption delay, that counts towards the intended maximum time slice
length we want to allow the thread.  In general, for untrusted users we must
take into account the possibility that they will always try to disable
preemption for as long as possible and just reap the exception messages.
Also, choosing appropriate sensitive priorities might not be easy if delayed
preemption is allowed.

But that is only the one reason.  The other reason is SMP.  Disabling
preemption is only atomic within a single processor.  If a thread on another
processor wants to cancel the next or current ipc of a thread, then
disabling preemption is not good enough.  The cancelling thread does not
even know if the other thread runs on the same CPU as itself, or some other
CPU.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/