From owner-cvs-all Wed Jun 27 22:14:23 2001 Delivered-To: cvs-all@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 14BB137B401; Wed, 27 Jun 2001 22:14:15 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f5S5EC548320; Wed, 27 Jun 2001 22:14:12 -0700 (PDT) (envelope-from dillon) Date: Wed, 27 Jun 2001 22:14:12 -0700 (PDT) From: Matt Dillon Message-Id: <200106280514.f5S5EC548320@earth.backplane.com> To: Doug Rabson Cc: John Baldwin , Jonathan Lemon Alfred Perlstein , "Brian F. Feldman" , Mike Silbersack , , , , Subject: Re: cvs commit: src/sys/netinet tcp_input.c tcp_output.c tcp_sub References: Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Matt, I think you are forgetting that on BSD/OS, when a lightweight :ithread hits a held mutex, it then converts to a fully scheduled :heavyweight thread, at which point any kind of preemption you can think of :can happen. :... :Doug Rabson Mail: dfr@nlsystems.com Yes, but that only applies to the interrupt thread, not the original thread that was interrupted, and it doesn't happen at a random point... it happens at a well defined point. The issue here is that the way it's implemented in FreeBSD, if the original non-interrupt thread is preempted by an interrupt the original thread could resume on another cpu, meaning that a thread cannot assume any sort of stable per-cpu state at any time, which creates huge performance/efficiency problems. BSDI didn't have this problem... a kernel thread could be preempted by an interrupt, but ONLY by an interrupt, and the kernel thread would always resume on the same cpu after the interrupt thread either completed or had to be scheduled (with no other thread being able to get that cpu in the mean time)... so in the BSDI implementation an interrupt works pretty much the way it works in 4.x. Thus in the BSDI scheme the cpu a thread is running on is 'stable'... can't be changed out from under the thread at random points. This allows threads to make significant optimizations in regards to accessing per-cpu data structures. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message