[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pthreads-users
Subject:    Re: [pthreads-users] when ngpt replace linuxthreads
From:       "Richard Seaman, Jr." <dick () seaman ! org>
Date:       2002-04-14 20:54:58
[Download RAW message or body]

On Fri, Apr 12, 2002 at 02:22:33PM -0400, Bill Abt wrote:

> On 04/12/2002 at 11:52:20 AM CST, "Andrew B. Lundgren"
> <Andrew.Lundgren@Level3.com> wrote:

[snip]
> > I would not want is this library
> > adopted as a standard distro lib until I knew it was not co-operative
> > multitasking internally.  Something I fear that it is from some of our
> > testing,
> > though I have not confirmed.
> 
> It is and it isn't...  Virtually every system call made by an application
> using NGPT is a preemption point, not just yields and sleeps.

I was wondering exactly what you meant here, so I took a look at what I
think are the wrappers for read() and write().  I appears to me (but I'm
really just asking if my analysis is correct) that what you mean is that
if a syscall would block in the kernel, you preempt it, let some other
thread(s) run in the mean time, and let the thread scheduler poll the
kernel to see when the syscall can be called without blocking.

Seems to me this is a very big difference from having a time-sliced
SCHED_RR policy, or a time-sliced SCHED_OTHER, which is what I tend
to assume that "pre-emptive threading" really means. 

While I don't think POSIX requires a pthreads implementation to have a
time-sliced scheduling policy, it is my impression (possibly misinformed)
that most of the commonly used UNIX/Linux implementations not only
have time-sliced scheduling policies, but that these are the default.
(eg. Solaris, FreeBSD, Linuxthreads).

Also, while a well designed and portable threaded app (if there is such
a thing -- real portablity seems very hard with threads) will not rely
on the existence of time-sliced scheduling, I suspect that enough
apps do implicitly or explicitly rely on this, so I would think that
it would be very hard to have NGPT be a complete "drop in" replacement
for Linuxthreads until you have a timesliced (default) policy.

> But, a
> thread in a tight loop can starve others in the process and that's not
> good.  We're currently working on method that we allow us to do fully
> preemptive scheduling but it's not yet ready for prime time.

I assume you are aware that the FreeBSD pthreads implementation, which is
purely a "user thread" (M:1) implementation, is fully preemptive (ie.
timesliced).  It basically steals the profile timer, and uses it to
trigger calls to the thread scheduler at approriate intervals.  The thread
scheduler is designed to be able to execute within the SIGPROF signal 
handler.  The thread scheduler has a little added complexity to handle
the per thread time accounting, but its not all that much more.  I assume
that for some good reason, this won't work for NGPT, but I thought I'd 
mention it anyway, just in case.


-- 
Richard Seaman, Jr.        email:    dick@seaman.org
5182 N. Maple Lane         phone:    262-367-5450
Nashotah WI 53058            fax:    262-367-5852
_______________________________________________
pthreads-users mailing list
pthreads-users@www-124.ibm.com
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/pthreads-users
[prev in list] [next in list] [prev in thread] [next in thread]