From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 18:08:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E1A016A4CE for ; Fri, 24 Sep 2004 18:08:15 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CED7E43D1D for ; Fri, 24 Sep 2004 18:08:14 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i8OI7T5f099608; Fri, 24 Sep 2004 14:07:29 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i8OI7SaR099605; Fri, 24 Sep 2004 14:07:28 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 24 Sep 2004 14:07:28 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Waldemar Kornewald In-Reply-To: <4152A3E9.8080700@web.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-net Subject: Re: locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2004 18:08:15 -0000 On Thu, 23 Sep 2004, Waldemar Kornewald wrote: > we at the Haiku networking team are considering a port of your 5.3 > netstack because it is thread-safe and making the old one (4.x, I think) > thread-safe is probably a much bigger task. > > Now, I saw that the routing code seems to use macros for the locking > code. Do you use macros everywhere? > > We would prefer having native threads and locks. Haiku only has > semaphores, not mutexes, is that a problem? > > Could you think of some other difficulties we could run into when > porting it? There are some sections of the network stack, such as the KAME IPSEC implementation, parts of IPv6, and some device drivers, which are not yet completely MPSAFE. This may or may not be an issue depending on what your requirements are. If you have any bug fixes or improvements, we would love to hear about them -- right now our locking is fairly coarse-grained but we'll be looking at contention issues over the next few months to see how best to refine our locking strategy. Regarding synchronization -- semaphores can be used to implement mutual exclusion, and so you could simply implement the locking macros in terms of semaphores rather than mutexes. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research