Date: Sun, 31 Oct 1999 23:43:22 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: eischen@vigrid.com, julian@whistle.com Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version II Message-ID: <199911010443.XAA26092@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
> > 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.) What happens under LinuxThreads? I'd expect an rfork'd process to get an equal share of processor time as it's parent. If I create 10 threads with PTHREAD_SCOPE_SYSTEM, I expect to have 10 LWPs (or rfork'd processes). What I am trying to say is that an application that creates 10 threads with PTHREAD_SCOPE_SYSTEM gets more processor time than 8 threads with PTHREAD_SCOPE_SYSTEM and 2 threads with PTHREAD_SCOPE_PROCESS. > > 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.. That's possible with scheduler activations, but not with something more like LinuxThreads. Under LinuxThreads, the threads library doesn't know when a thread has been swapped out, so if it owns a critical resource (let's say a spinlock), a higher priority thread wanting the same lock will spin continously and not let the other thread run. You have to push the locking mechanisms down into the kernel to solve this. I don't want the threads library to have to make a system call for internal library locking, but if you want a set of goals free from implementation, there it is... 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?199911010443.XAA26092>