Date: Thu, 17 Apr 2003 09:19:44 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch Message-ID: <3E9ED420.41E89DDA@mindspring.com> References: <Pine.GSO.4.10.10304170519410.5432-100000@pcnet1.pcnet.com> <001d01c304c6$60b13dd0$f001a8c0@davidw2k>
next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote: > > > > If it wasn't possible for the kernel to send completed > > > > threads from one KSE to another (within the same KSE > > > > group), we probably wouldn't need critical sections > > > > (at least as currently implemented). > > > > > > Is there a particular performance/other reason this is allowed? > > > > I dunno. The original Jasone Evans paper didn't allow this, but > > the Anderson SA paper did (although our version of KSE's is a bit > > different than SA). > > Because there is no benefit for kernel side, whether you use one > completed list per-ksegrp or one completed list per-upcall context, > there is always competion between threads trying to export their > contexts, so using one completed list is simple way to go, if we > use completed list per-upcall context, there is other things we > would worry about. So dual-map the pages containing them, into both kernel and user space, and be done with it. Add a seperate read-only mapping to a read/write mapping, and point to one in the other, if you're concerned about protecting some kernel data from the user space process. This doesn't need to be so hard. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E9ED420.41E89DDA>