Date: Sat, 12 Aug 2000 09:39:54 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: hackers@freebsd.org Cc: jonas.bulow@servicefactory.se Subject: Re: IPC, shared memory, syncronization Message-ID: <200008121639.JAA63479@vashon.polstra.com> In-Reply-To: <3995431A.324F8C89@servicefactory.se> References: <39943C37.76D2DBCC@servicefactory.se> <39948331.5E83DE1B@servicefactory.se> <200008120230.TAA60410@vashon.polstra.com> <3995431A.324F8C89@servicefactory.se>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <3995431A.324F8C89@servicefactory.se>, Jonas Bulow <jonas.bulow@servicefactory.se> 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). Fair enough. It's a trade-off between simplicity and overhead and it depends also on the amount of contention you expect for the locks. > 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. Well, there is alpha code there too. :-) > 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? It depends on the amount of contention you expect. The code in lockdflt.c was designed for a very low-contention situation (usually no contention at all). It also had to work in a very restrictive environment where the threads package was unknown and could be practically anything. Also it was designed to do locking between two threads running in the same process, which is not the problem you're trying to solve. Your environment is much more controlled, so you can probably do better. I think the ideal solution would first try to lock the test-and-set lock, maybe spinning on it just a few times. If that failed it would fall back to using a system-call lock such as flock() which would allow the process to block without spinning. But I don't have any code to do that. (If you write some, could I have a copy?) > In lock_create the lock is aligned to CACHE_LINE_SIZE. Why is that > important? It's just more efficient that way. The spinlock tends to hammer the cache line containing the lock (i.e., invalidate the whole line over and over). If anything else is also accessing the same cache line, there is a big performance penalty. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa 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?200008121639.JAA63479>