From owner-freebsd-hackers Wed Jul 1 14:18:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24179 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 14:18:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24139 for ; Wed, 1 Jul 1998 14:17:56 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id OAA22239; Wed, 1 Jul 1998 14:17:57 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd022214; Wed Jul 1 14:17:50 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA15402; Wed, 1 Jul 1998 14:17:47 -0700 (MST) From: Terry Lambert Message-Id: <199807012117.OAA15402@usr05.primenet.com> Subject: Re: mlock()/mclear (was Re: Unsupport calls) To: dbj@iglou.com (David E. Brooks Jr) Date: Wed, 1 Jul 1998 21:17:47 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: from "David E. Brooks Jr" at Jul 1, 98 05:05:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Then (if I'm digesting this correctly) what you're saying is the > MAP_HASSEMAPHORE flag isn't necessary under FreeBSD because the kernel > already keeps everything nice and synchronized because of the unified > VM and buffer caches, right? And the automatic cache coherency of the software. But like using msync() on FreeBSD, MAP_HASSEMAPHORE is *not* optional on other platforms, and correct code will use it (as correct code on other platforms will use msync(); INN was a disaster for a long time in this regard). > BTW, I misspoke when I originally was talking about mlock()/mclear(). > I meant mset()/mclear() (and their associates msleep() and mwakeup()), > which are the partially user mode semaphores I'm looking into > implementing for FreeBSD (they're described in newvm paper in > /usr/share/doc/papers and 4.4 BSD design book). > > It goes to show that NyQuil and thinking don't mix...Sorry if I > confused anyone. the sleep and wakeup functions need to be kernel coordinated, as do the set/clear in the case of a 0->1, 1->0 transition resulting in an "event" that results in a wakeup. These can be proxies for tsleep()/wakeone(), actually, with whatever appropriate base memory address trickery to keep the tsleep out of collision with other tsleep calls in the kernel itself. > Oh, when I do start to actually work on this, who do I need to > coordinate with? I believe David Greenman is the correct person for VM related issues, now that John Dyson has left the project. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message