Date: Wed, 1 Jul 1998 21:17:47 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dbj@iglou.com (David E. Brooks Jr) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: mlock()/mclear (was Re: Unsupport calls) Message-ID: <199807012117.OAA15402@usr05.primenet.com> In-Reply-To: <Pine.BSF.3.96.980701161722.227A-100000@localhost> from "David E. Brooks Jr" at Jul 1, 98 05:05:42 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807012117.OAA15402>