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, Bill
Attachment:
pgpndz6tueJ5P.pgp
Description: PGP signature