Date: Sat, 12 Aug 2000 13:39:42 -0400 (EDT) From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Jonas Bulow <jonas.bulow@servicefactory.se> Cc: hackers@freebsd.org Subject: Re: IPC, shared memory, syncronization Message-ID: <Pine.BSF.4.21.0008121329570.81297-100000@green.dyndns.org> In-Reply-To: <3995431A.324F8C89@servicefactory.se>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0008121329570.81297-100000>