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! /
[EMAIL PROTECTED] `------------------------------'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
