From owner-freebsd-stable Wed Apr 28 13:58: 3 1999 Delivered-To: freebsd-stable@freebsd.org Received: from boromir.vpop.net (dns1.vpop.net [206.117.147.2]) by hub.freebsd.org (Postfix) with ESMTP id B48431578A for ; Wed, 28 Apr 1999 13:57:58 -0700 (PDT) (envelope-from mreimer@vpop.net) Received: from vpop.net ([216.160.82.65]) by boromir.vpop.net (8.9.1/8.9.1) with ESMTP id NAA18941 for ; Wed, 28 Apr 1999 13:57:58 -0700 (PDT) Message-ID: <37277653.1EF64476@vpop.net> Date: Wed, 28 Apr 1999 13:57:55 -0700 From: Matthew Reimer Organization: VPOP Technologies, Inc. X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.8-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: MFC pthreads before 3.2 is released? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Would someone MFC Dan's/John's threads patches before the 3.2 freeze? The reason is performance; to quote a post by Richard Seaman: > On another note, the recent changes to the FreeBSD user > pthreads code, which you committed on about March 22, > appears to be a major improvement in this code. On my > very crude benchmarks, the linuxthreads port used to > beat the heck out of the uthread code. This is no longer > true. Most tests show them about equal, except that uthread > context switches are now much faster than the linuxthreads code, > as they should be (before March 22 uthread was slower). Date: Mon, 22 Mar 1999 21:11:30 -0800 (PST) From: John Birrell To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/include pthread.h pthread_np.h Message-ID: <199903230511.VAA13715@freefall.freebsd.org> jb 1999/03/22 21:11:30 PST Modified files: include pthread.h pthread_np.h Log: o Runnable threads are now maintained in priority queues. The implementation requires two things: 1.) The priority queues must be protected during insertion and removal of threads. Since the kernel scheduler must modify the priority queues, a spinlock for protection cannot be used. The functions _thread_kern_sched_defer() and _thread_kern_sched_undefer() were added to {un}defer kernel scheduler activation. 2.) A thread (active) priority change can be performed only when the thread is removed from the priority queue. The implementation uses a threads active priority when inserting it into the queue. A by-product is that thread switches are much faster. A separate queue is used for waiting and/or blocked threads, and it is searched at most 2 times in the kernel scheduler when there are active threads. It should be possible to reduce this to once by combining polling of threads waiting on I/O with the loop that looks for timed out threads and the minimum timeout value. o Functions to defer kernel scheduler activation were added. These are _thread_kern_sched_defer() and _thread_kern_sched_undefer() and may be called recursively. These routines do not block the scheduling signal, but latch its occurrence. The signal handler will not call the kernel scheduler when the running thread has deferred scheduling, but it will be called when running thread undefers scheduling. o Added support for _POSIX_THREAD_PRIORITY_SCHEDULING. All the POSIX routines required by this should now be implemented. One note, SCHED_OTHER, SCHED_FIFO, and SCHED_RR are required to be defined by including pthread.h. These defines are currently in sched.h. I modified pthread.h to include sched.h but don't know if this is the proper thing to do. o Added support for priority protection and inheritence mutexes. This allows definition of _POSIX_THREAD_PRIO_PROTECT and _POSIX_THREAD_PRIO_INHERIT. o Added additional error checks required by POSIX for mutexes and condition variables. o Provided a wrapper for sigpending which is marked as a hidden syscall. o Added a non-portable function as a debugging aid to allow an application to monitor thread context switches. An application can install a routine that gets called everytime a thread (explicitly created by the application) gets context switched. The routine gets passed the pthread IDs of the threads that are being switched in and out. I found this useful, but we can get rid of it if you want. Submitted by: Dan Eischen Revision Changes Path 1.11 +71 -36 src/include/pthread.h 1.6 +7 -0 src/include/pthread_np.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message