Date: Thu, 19 Jun 2003 23:36:29 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: Implementing TLS: step 1 Message-ID: <3EF2AB6D.67145D17@mindspring.com> References: <Pine.BSF.4.21.0306191523190.41210-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > It doesn't see the userland threads and knows nothing aboyut them so it > is physically incapable of setting the register to point to them. > > (though it COULD save and restore the value for threads that have > enterred the kernel I guess, (blindly hoping that they make sense)) This adds the assumption that, following an involuntary context switch, when the next quantum is allocated to the KSE, the thread that was running under that KSE is the one which will be activated, regardless of priority relative to other threads. It further assumes that the thread will not be migrated to another KSE (e.g. on another CPU which is assigning quantum to the process, while the KSE in question is the only one in the "runnable" state in the process at the time of the assignment). Neither of these are valid assumptions. The first one breaks already, in the current implementation, if you are not running a hacked user space scheduler. I don't think this is a reasonable direction to go. Your own suggestion that a second indirection is needed to get the actual thread (and TLS context pointer) is correct, IMO. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EF2AB6D.67145D17>