From owner-freebsd-hackers Sat Aug 12 10:39:47 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 82E1D37B69D; Sat, 12 Aug 2000 10:39:43 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sat, 12 Aug 2000 13:39:42 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Jonas Bulow Cc: hackers@freebsd.org Subject: Re: IPC, shared memory, syncronization In-Reply-To: <3995431A.324F8C89@servicefactory.se> 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 Sat, 12 Aug 2000, Jonas Bulow wrote: > John Polstra wrote: > > If you want the "BSD way" you should probably create a 0-length > > temporary file somewhere and use the flock(2) system call on it. The > > file itself isn't important; it's just something to lock. > > I don't see any reason to do system calls just because I want to do an > atomic operation (i.e aquire/release a lock). > > I found some really good code (:-)) in > /usr/src/libexec/rtld-elf/i386/lockdflt.c that seems to do what I want. > It's more the "i386"-way than the BSD-way. Maybe I havn't been thinking > enough but wouldn't this lock mechanism be a good choice to use for > mmaped:memory accessed by multiple processes? I was just going to suggest this =) The best way to go about this method is, IMHO, to map a range of memory you'll get "locks" from and use that as a zone-type allocator. For the most part, you can reuse lockdflt.c for the i386 and alpha archs and it will probably work well :) The caveats are that you need to have mmap()-shared locks themselves, if you're not threaded you'll probably want to take all the signal-related stuff out. If you don't need shared locks, you can simplify things by just using machdep cmpxchgl() and cmp0_and_store_int() routines, along with probably wanted to do a nanosleep() like the rtld-elf code, too. I assume if you were doing things with threads, you'd be using the pthread_mutex_t routines, of course ;) > In lock_create the lock is aligned to CACHE_LINE_SIZE. Why is that > important? I'm thinking it's to keep things in one line of the data cache so as to not impact performance more than necessary. I didn't really pay attention to this part of the implementation, but it makes sense to me :) -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message