From owner-freebsd-hackers Sat Aug 12 5:29:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from oden.exmandato.se (oden.exmandato.se [192.71.33.1]) by hub.freebsd.org (Postfix) with ESMTP id 5770E37B891 for ; Sat, 12 Aug 2000 05:29:20 -0700 (PDT) (envelope-from jonas.bulow@servicefactory.se) Received: from servicefactory.se (root@oden.exmandato.se [192.71.33.1]) by oden.exmandato.se (8.8.8/8.8.5) with ESMTP id OAA06989 for ; Sat, 12 Aug 2000 14:29:17 +0200 (MET DST) Message-ID: <3995431A.324F8C89@servicefactory.se> Date: Sat, 12 Aug 2000 14:29:14 +0200 From: Jonas Bulow X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: IPC, shared memory, syncronization References: <39943C37.76D2DBCC@servicefactory.se> <39948331.5E83DE1B@servicefactory.se> <200008120230.TAA60410@vashon.polstra.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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? In lock_create the lock is aligned to CACHE_LINE_SIZE. Why is that important? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message