From owner-freebsd-hackers Mon Aug 14 2:35: 6 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 5CCD937B6B9 for ; Mon, 14 Aug 2000 02:35:01 -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 LAA26221 for ; Mon, 14 Aug 2000 11:34:58 +0200 (MET DST) Message-ID: <3997BD3E.2B65AD19@servicefactory.se> Date: Mon, 14 Aug 2000 11:34:55 +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 AND threads... References: <39943C37.76D2DBCC@servicefactory.se> <39948331.5E83DE1B@servicefactory.se> <200008120230.TAA60410@vashon.polstra.com> <3995431A.324F8C89@servicefactory.se> <200008121639.JAA63479@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: > Jonas Bulow wrote > > 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 I'm trying to solve the threading-problem too. The overall architecture is a preforked server where there is a need to share information between all threads in all preforked processes. The solution below seems to be good if flock doesn't block all threads in a process, that is. > > 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?) I am about to. I don't know it it's bad design to have rtld.c export lockdflt_init in the same way as dlopen, what di you think? /jonas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message