Date: Mon, 12 Aug 1996 09:54:21 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: igor@jabber.paco.odessa.ua (Igor Khasilev) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD vs. NT Stability Message-ID: <199608121654.JAA25508@phaeton.artisoft.com> In-Reply-To: <199608120912.MAA21871@jabber.paco.odessa.ua> from "Igor Khasilev" at Aug 12, 96 12:12:33 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>> So my question is: how does NT behave when it has to schedule between a >> large number of processes each with its own process context, VM, page tables >> etc? Conversely how does the unix program behave when linked with -lpthreads >> and with `fork()' replaced with `pthread_create()'? > > One bad thing with user level threads (actualy pthreads that I used): > sheduler which runs on user lever ALWAYS consume processor time (even wnen > all threads sleeps), and permanenly keep part of code in memory. If it is > true (maybe I misunderstand something), then pthreads is bad solution for > heavy loaded systems. This should not be true if it is implemented correctly. It is either using signals to switch (like "sigsched" threads) or it is using async I/O and aiowait() when no context is active, using conversion of sync I/O to async I/O + a context switch (like SunOS 4.x LWP), or it is using descriptor hybridization and is using select internally as its "aiowait" async I/O equivalent (where the I/O is not posted until such time as it would not block). In any of these implementations, user space threads do not "ALWAYS consume processor". The *point* of user space threads is to consume as much of your process quantum as you can possibly consume. The idea is that the process quantum is something the system gives a process, and by God, it's the right of that process to consume as much of the quantum as possible. The general problem with kernel threads is that they are typically lazy implementations. In general, a kernel threads implementation takes a blocking I/O, and blocks the context making the call, and switches. On an unloaded machine, it switches to another thread in the same context; on a loaded machine, it's as expensive as the process context switch, because it's statistically unlikely to schedule threads in the same process concurrently (if the scheduler is hacked to allow that, then other processes can dies of starvation). A process using user level threads competes with other processes as if it were one process (ie: it is awarded one quantum). A process using kernel threads competes with other processes as if it were the number of processes equal to the number of kernel threads allocated to the process. A kernel threaded process must allocate as many kernel threads as it has potential simultaneous outstanding blocking calls, or it will suffer quantum starvation on one or more of it's threads. This is evil, because the system gave the quantum to the process, and the kernel thread gave the remainder of the quantum back to the system without giving another kernel thread in the same process the option of using the remainder. Obviously, the ideal mechanism is combined kernel and user threads, with cooperative scheduling of kernel process quantums in user space against the thread contexts that are blocked awaiting quantum. This will result in the best overall utilization with the fewest true context switches. The primary benefit of kernel threads is SMP scalability of parallelizable algorithms. The secondary benefit of kernel threads is in terms of quantum allocability as a gross measure of how zealously you want to let your threads compete with other processes which are also competing for quantum. There are a number of usenet discussions on threading between myself and engineers at Sun and elsewhere; you can look them up on Dejanews. Since kernel threading is heavily related to SMP scalability of processes, the SMP group of FreeBSD has dealt some with the issue. One very good engineer has implemented kernel threading on FreeBSD, and the code has been submitted; from what I understand, the code will be integrated into the final SMP release, with only minor changes. The resoloution of the kernel threading quantum and context switch problems (current problems for both SVR4 and Solaris threading, which are derived from the same Sun code base) will have to wait for better async->sync call conversion. In all likelihood, this will be implemented by adding a system call for a more generic "aiowait/aiocancel" that is not so I/O bound, and an alternate system call vector to allow all potentially blocking system calls to be converted to queued calls plus a user space context switch. In this way, the kernel threading problem of blocking thread execution and throwing away perfectly good quantum on process context switches, can be eliminated. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608121654.JAA25508>