From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:31:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46567106567E; Sat, 24 Jan 2009 23:31:30 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 08F408FC08; Sat, 24 Jan 2009 23:31:29 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5416649rvf.43 for ; Sat, 24 Jan 2009 15:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1A2A6DBf9LVciepX/aK5BqI5zYpM0cPOoFPfYUh5erg=; b=tkrtaYDpG6tImDOmI2eKEHYcL1jGDtsFirr7ugclZYsMxSmz+uWy/HKD3V1i9b1ofB IgQlnFBusy6HbkqFgZIxvg1gDCfHSUXm/C4bhI/+w2+lOWURZwAunJQnwh++05GA9eOZ jt3DrIdl+KeSAJDy+DQQ8D0N2dmX3cV41Kq7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Nck4kSTXkWBUsCPhU4Y+EQwN0YD6uGDMVA/6O2N1h1IqPWX2yZAZe67a0huY90BQlW OdFYcqOs2sTe+IXHx7lvC/i7XsxC35kcTD/dumg7cZwuaosBA1lAXr/q02Qb1U9mF1rw SCZ+K4iWMYFWZGnx+6KqM7tuKu/KOnuShe5tI= MIME-Version: 1.0 Received: by 10.141.20.6 with SMTP id x6mr1188233rvi.159.1232839889648; Sat, 24 Jan 2009 15:31:29 -0800 (PST) In-Reply-To: <497BA0F2.5080004@elischer.org> References: <20090123154336.GJ60948@e.0x20.net> <200901232337.05627.hselasky@c2i.net> <200901240952.21670.hselasky@c2i.net> <497BA0F2.5080004@elischer.org> Date: Sat, 24 Jan 2009 15:31:29 -0800 Message-ID: From: Maksim Yevmenkin To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2009 23:31:30 -0000 On Sat, Jan 24, 2009 at 3:14 PM, Julian Elischer wrote: > Maksim Yevmenkin wrote: >> >> Hans Petter, > >>> Do mutexes sleep? No? So my code should be fine? >> >> yes, regular mutexes sleep. > > Yes and no. > > This is a semantic thing.. > > They don't actually 'sleep', but they do deschedule the thread. > > the difference is purely semantic. > > Users of mutexes "agree" to never do anything that in indeterminately long > while holding the mutex so you are SUPPOSED to get control back in a "short" > period of time. Even if multiple mutexes have > dependencies on each other, the fact that none of them may wait > for a "long" time is suposed to guarantee that your thread should get > control again "shortly". > > It is illegal to sleep while holding a mutex. This helps enforce > this (otherwise small) distinction. > > A Sleep may wait for an arbitrary amount of time.. e.g. until reboot. > so doing so with a mutex held would break the agreement. > > Effectively the only real difference is that the agreement > by users to not use a mutex when things may get slow. > > Spin locks are even more strict.. > > BTW A mutex that is waiting on a thread on another processor > may spin for a short amount of time before taking the expensive > step of descheduling the thread. yes, i guess i used "sleep" word too much and it became overloaded. as i tried to explain in previous email, when i talk about "sleep" i really mean de-schedule. in any case, i sent another patch to Hans Petter (privately) which hopefully addresses most of his concerns. as i understood, the biggest was excessive amount of NG_XXX macros and node reference counting. all of those are now mostly gone and the resulting code is more clean (or so i hope). i kept async design which allows to completely decouple netgraph from usb2 and, like i said, it is a "good thing(tm)" thanks, max