Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Jun 2001 22:14:12 -0700 (PDT)
From:      Matt Dillon <dillon@earth.backplane.com>
To:        Doug Rabson <dfr@nlsystems.com>
Cc:        John Baldwin <jhb@FreeBSD.org>, Jonathan Lemon Alfred Perlstein <bright@sneakerz.org>, "Brian F. Feldman" <green@FreeBSD.org>, Mike Silbersack <silby@FreeBSD.org>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org>, <jlemon@FreeBSD.org>, <bmilekic@FreeBSD.org>
Subject:   Re: cvs commit: src/sys/netinet tcp_input.c tcp_output.c tcp_sub
Message-ID:  <200106280514.f5S5EC548320@earth.backplane.com>
References:   <Pine.BSF.4.33.0106272128380.96893-100000@herring.nlsystems.com>

next in thread | previous in thread | raw e-mail | index | archive | help
: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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106280514.f5S5EC548320>