Source-Changes archive

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

Re: CVS commit: src/sys/compat/sa

On Mon, Oct 27, 2008 at 08:24:06PM +0100, Christoph Egger wrote:
> Bill Stouder-Studenmund wrote:
> > 
> > If I'm wrong, I think the thing to do is disable kernel preemption in 
> > sa_upcall().
> With kernel preemption enabled, curlwp may unlock a different lwp than
> the one you locked.
> If you are sure, curlwp never changes between lock and unlock, then
> my complaint is pointless. But if it can, then you have to either cache
> curlwp in a variable or disable kernel preemption for this code section.

How could curlwp unlock a different lwp?

I agree that with preemption, curlwp could change during the call. Another 
thread could get run. However for our unlock to run, we have to have been 
switched _back_ to our context, so curlwp is back to whatever it was when 
our routine started.

I agree curcpu could have changed, or that curlwp changes from call to
call. But I'm just not getting how any given subroutine (that's not part
of the scheduler code) will see curlwp change across the duration of a
call. Please help me understand this!

Take care,


Attachment: pgpndz6tueJ5P.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index