From owner-freebsd-current Sat Nov 24 16:42:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from noos.fr (r178m112.cybercable.tm.fr [195.132.178.112]) by hub.freebsd.org (Postfix) with ESMTP id 9251237B418 for ; Sat, 24 Nov 2001 16:42:05 -0800 (PST) Received: (from mux@localhost) by noos.fr (8.11.6/8.11.4) id fAP0g0N01103; Sun, 25 Nov 2001 01:42:00 +0100 (CET) (envelope-from mux) Date: Sun, 25 Nov 2001 01:42:00 +0100 From: Maxime Henrion To: Hiten Pandya Cc: current@FreeBSD.org Subject: Re: some info Message-ID: <20011125014200.A831@nebula.noos.fr> References: <20011125002202.19785.qmail@web21109.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011125002202.19785.qmail@web21109.mail.yahoo.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hiten Pandya wrote: > hi all, > sorry for running -current.. but i am an enthusiastic > and challenging man...(boy)... > > anyways.. whats a mutex and a lock order reversal... > if you could point to some good manual on these > subjects... thanks... > > help is appreciated... > > thanks again... A mutex is an algorithmic object used to serialize operations. It stands for ``mutual exclusion''. It's useful when the same code is ran several times in parallel. For example, if two threads wanted to modify a linked list in the same time, there is a chance that the linked list would get corrupted since an insert or remove operation is not atomic (one of the thread could get preempted when it has not finished to remove or insert an element, and thus the linked list is not in a normal state). In such cases, every part of the code that modify the linked list has to obtain the mutex before doing it and release after. If another thread tries to acquire the mutex, it will block until the first thread has released it. When some code has to obtain two locks or more, deadlocks might happen. If thread 1 has lock A and tries to acquire lock B while thread 2 has lock B and wants lock A, then both threads will block indefinitely. To solve this, one way is to always obtain the lock in the same order. The warning messages you got show that some code is violating this lock order somewhere. I found ``Unix Internals'' from Uresh Vahalia to be a very good book on this topic. Hope this helps, Maxime Henrion -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message