Date: Wed, 1 Jul 1998 17:05:42 -0400 (EDT) From: "David E. Brooks Jr" <dbj@iglou.com> To: Terry Lambert <tlambert@primenet.com> Cc: hackers@FreeBSD.ORG Subject: Re: mlock()/mclear (was Re: Unsupport calls) Message-ID: <Pine.BSF.3.96.980701161722.227A-100000@localhost> In-Reply-To: <199807011822.LAA29206@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 1 Jul 1998, Terry Lambert wrote: > > > It is trivial to implement p/v semaphores using __asm__ to generate > > > single instruction spinlocks; since the VM/buffer cache is unified, > > > this will work on shared memory/mmap'ed files without needing a > > > special system call to guaranteee lock coherency. > > > > Funny you should mention this. I was poking around the man page to > > mmap() the other day looking for any hints on a "standard" way to > > perform inter-process synchronization when sharing memory. This led > > me to read the 'newvm' paper, specifically about > > mlock()/mclear(). Well, to make a short story even shorter, I ended up > > having a brief e-mail exchange with David Greenman where he said in my > > mail batch this morning "...a bright beginner could tackle it." > > > > So, I figured I'd try and find out how bright I really am <grin>. > > Look at the SMP locking code; it handles all of this. Specifically, > look at the big giant kernel reentrancy lock. > > > I haven't gotten very far (I'm re-reading relevant portions of _The > > Design and Implementation of 4.4 BSD Operating System_ and lots of > > stuff in section 9 right now), but I do have one question right off > > the bat. Both mmap(2) and the newvm paper make mention of the > > MAP_HASSEMAPHORE flag; Why is (or was) this necessary? All that comes > > to mind is multi-processor systems and keeping any copies of that > > page of memory synchronized. > > SMP synchornization is automatic, via IPI (Inter Processor Interrupt) > as part of the APIC (Advanced Programmable Interrupt Controller) that > is built into the CPU. Intel supports full MESI cache coherence. > > The place you need MAP_HASSEMAPHORE is when you need to take action > to synchronize the memory. [A lot of Terry's informative dissertation trimmed for space] 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? 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. Oh, when I do start to actually work on this, who do I need to coordinate with? -- Dave -- David E. Brooks Jr dbj@iglou.com 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?Pine.BSF.3.96.980701161722.227A-100000>