Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 Oct 1999 19:56:34 -0800 (PST)
From:      Julian Elischer <julian@whistle.com>
To:        Daniel Eischen <eischen@vigrid.com>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: Threads goals  version II
Message-ID:  <Pine.BSF.4.05.9910311939500.8816-100000@home.elischer.org>
In-Reply-To: <199911010331.WAA18647@pcnet1.pcnet.com>

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


On Sun, 31 Oct 1999, Daniel Eischen wrote:

> > 6/ (contentious) multiple theads should be bound to within the resource
> >         limits of the single process.
> 
> Multiple processes/LWPs should be allowed to have their own quantum and
> not count towards the [parent] process quantum, right?

Usually wrong.. usually the desired behaviour is to allow the multiple
threads to share the resources (including processors) that are allocated
to the process as a whole. If you are the only process running, your
threads get to use 100& of cputime.
If you are timesharing with 4 other people your threads get to share 20%
of the cpu (on average).  In reality you will do better than the otherrs
as you won't be blocked as much as a single threaded process.

I would think that the way to do this would be to expand the priority of
the process as a whole and then let your own scheduler (within the
process) decide which threads get the time.

But that's implementation.

do you really want wht you said? It's kind of hard to believe you really
want that..
Unless you want to declare a set of kernel shedulable entities to be 
given their own scheduling group, which would be something you'd have to
ask for explicitly.

if all teh threads running in a process were doing some sort of
'continuation' scheme, then you migh tuse the 'rfork' schem to produce a
second schedulable set of entities that didn't share with the first.
(but now we're getting into implementation again.)


> 
> > 9/ there exists a set of primatives that allow threads to influence the
> > in-process scheduling between themselves.
> 
> This should also be across multiple LWPs also.  Perhaps we need to
> state our terminology - I'm not sure if this is what you meant.

There are processes. Processes own resources (including a share of the
processor time). One process may have a number of kernel schedulable
entities, or, stated backwards, a number of shedulable entities that share
all their resources are grouped together as a single process. Then in user
land there may be several threads of control. They may switch between
themselves tranparently to the kernel. it is totally unaware of them. It
knows only of the scedulable entities..

This is how I'm starting to envision things from what's been said so far.


> 
> > 14/ your goals here..
> 
> The ability for the threads library to protect internal data structures
> to be safe from priority inversion problems when using multiple LWPs.

Priority inversion and inheritance within the userland scheduler..



> 
> Dan Eischen
> eischen@vigrid.com
> 





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.05.9910311939500.8816-100000>