Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Nov 1999 14:40:52 -0800 (PST)
From:      Julian Elischer <julian@whistle.com>
To:        "Louis A. Mamakos" <louie@TransSys.COM>
Cc:        Daniel Eischen <eischen@vigrid.com>, Matthew Dillon <dillon@apollo.backplane.com>, "Daniel C. Sobral" <dcs@newsguy.com>, freebsd-arch@freebsd.org
Subject:   Re: Threads 
Message-ID:  <Pine.BSF.4.10.9911241405570.11412-100000@current1.whistle.com>
In-Reply-To: <Pine.BSF.4.10.9911241207100.11412-100000@current1.whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help

I think matt ha sa point but it doesn't necessarily cover all the
requirements that complying with posix threads brings us.


The system we suggest includes an escape mechanism whereby
the blocked KSE is 'replaced immediatlyby a new one, that is made
available to the Userlevel Thread Scheduler (UTS). 
If this feature is not enabled (the appliation has to turn it on 
when it has enough of itself set up to handle it) then we effectively have 
Linux threads, or with only one process, our current threads.

here are some common points that I think everyone agrees on:

The proc structure get's broken down to separate out those parts needed 
to schedule. (i.e. context etc)

When a KSE blocks, that stack and context are effectively frozen, just as
they are now.

where we differ is what happens next. In Matt's system new KSE is created
and run and a different userland context is chosen and scheduled by the
kernel on that KSE. (as it has all the userland contexts stored somewhere.

In ours, a new KSE is created and run and the UTS is invoked which does
the same job but in userland.

In Matt's system a 'yield()' call is a system call, where in ours it's
something similar to a setjmp + calling the UTS.

In Matt's system creating a new user thread context requires making a
syscall (to save the context of whichever thread doesn't continue after
the call).

The difference is in who has access to what information. The same task is
being done in each case, but where?

In the "kernel thread Scheduler" (KTS?) model the kernel has to know all
the information required for scheduling these threads. The Userland needs
to know this too to some extent to decide when to migrate threads around
between processors and how and when to change priorities. (which it needs
to do via syscalls). The sceduling methods are liitted to what the kerlel
supports.

In the UTS model, the kernel is oblivious to what threads are being
scheduled onto the KSEs.

Both systems could work. 

I think we need pictures :-)







To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9911241405570.11412-100000>