From owner-freebsd-hackers Wed Jul 1 14:05:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA21470 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 14:05:40 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iglou.com (sendmail@iglou2.iglou.com [192.107.41.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA21452 for ; Wed, 1 Jul 1998 14:05:32 -0700 (PDT) (envelope-from dbj@iglou.com) Received: from lou-ts8-22.iglou.com ([204.255.238.185] helo=localhost) by iglou.com with smtp (8.7.3/8.6.12) id 0yrU46-0000Ci-00; Wed, 1 Jul 1998 17:05:19 -0400 Date: Wed, 1 Jul 1998 17:05:42 -0400 (EDT) From: "David E. Brooks Jr" X-Sender: dbj@localhost To: Terry Lambert cc: hackers@FreeBSD.ORG Subject: Re: mlock()/mclear (was Re: Unsupport calls) In-Reply-To: <199807011822.LAA29206@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 . > > 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