[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: deferred cancellation of ipc

From: Marcus Brinkmann
Subject: Re: deferred cancellation of ipc
Date: Wed, 15 Oct 2003 01:49:54 +0200
User-agent: Mutt/1.5.4i

On Tue, Oct 14, 2003 at 04:00:35PM -0700, Volkmar Uhlig wrote:
> After reading your initial scenario again there is a rather simple
> solution--use zero timeouts.  Instead of storing the cancel flag you
> store the intended send timeout value, which could be zero.  Of course
> you still run into a race on MP if you don't use some synchronization
> primitive, but that is a different issue you have to deal with anyway.  
> This solution assumes that you _only_ want to ensure that the thread
> does not block.

That doesn't seem to give me any relief.  If I see the zero timeout in my
thread for the IPC, I can also see a cancel flag and exit right away.  I can
do a quick poll on the IPC, if I want to, but as you said, the
synchronization problem has to be solved, because the race happens if the
cancel happens after I checked the cancel flag and before I enter the IPC
> > Or does maybe stopping a thread on another CPU count as 
> > preemption and is also delayed?
> Sorry, but I don't get what you mean.  What is "stopping"; exregs?

Yes.  Also called halting.  If I stop/halt a thread on another cpu, will
this stop/halt the thread even if it delayed preemption?  Or does preemption
delay prevent that?


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]