From owner-freebsd-threads@FreeBSD.ORG Wed Mar 29 10:08:33 2006 Return-Path: X-Original-To: threads@freebsd.org Delivered-To: freebsd-threads@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 242F016A41F; Wed, 29 Mar 2006 10:08:33 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DCDB43D46; Wed, 29 Mar 2006 10:08:32 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 8ED8D209F; Wed, 29 Mar 2006 12:08:27 +0200 (CEST) X-Spam-Tests: AWL,BAYES_00,FORGED_RCVD_HELO X-Spam-Learn: ham X-Spam-Score: -2.4/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 07308209D; Wed, 29 Mar 2006 12:08:27 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id DE92933C8D; Wed, 29 Mar 2006 12:08:26 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: David Xu References: <86slp1u4qb.fsf@xps.des.no> <442A466A.9040506@freebsd.org> <861wwlehvg.fsf@xps.des.no> <442A55EB.9060009@freebsd.org> Date: Wed, 29 Mar 2006 12:08:26 +0200 In-Reply-To: <442A55EB.9060009@freebsd.org> (David Xu's message of "Wed, 29 Mar 2006 17:39:55 +0800") Message-ID: <86k6add0md.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: threads@freebsd.org, jeff@freebsd.org Subject: Re: libthr cleanup X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 10:08:33 -0000 David Xu writes: > Dag-Erling Sm=F8rgrav wrote: > > In effect, the wait / wake operations implement a condition variable. > > You should not use the same struct (or type) to describe the condition > > variable as the one you use to describe a mutex. > > Condition variables are always used in conjunction with a mutex. The > > mutex must be passed to the wait function so it can be unlocked while > > the waiting thread waits. It must be held by the thread calling the > > wake method. Neither the existing interface nor the one you propose > > do this. > You are talking about how to use it, not how to implement it. No, I am talking about how to implement it. If you try to implement condition variable primitives which do not require a mutex to be held, your condition variables will not work; they may work most of the time, but there will be races. > > You cannot "wait for an integer to be changed" (at least not without > > using hardware debugging facilities), and that is not what > > UMTX_OP_WAIT does. It is a botched condition variable. It waits for > > another thread to perform an UMTX_OP_WAKE operation with the correct > > arguments; the fact that an integer has changed is incidental, and the > > test for that change could be implemented in userland: look up > > condition variables in any good CS textbook and you will see an > > example of this, likely in the guise of a sample message queue (or > > mailbox) implementation. > again, there are many ways to implement it, I think you are talking > about how to use it, not how to implement it. Again, I am talking about how to implement them. See above. The counter ("integer to be changed") is necessary to avoid races when multiple threads are sleeping on the same condition variable - but the counter itself must be protected, which is what the mutex is for. You can't sleep with that mutex held, because the signalling thread needs to hold the mutex while incrementing the counter and signalling the sleeping threads. The only way to achieve this is to pass the mutex to the wait function, so the wait function can drop it (and later reacquire it) in a critical section. If you remove the mutex, you need to protect your counter with a critical section; but then you no longer have a condition variable, but a counting semaphore. If you remove the counter, all you have left is some kind of multicast asynchronous signal. > I don't trust you, I don't think your work is useful to me, you are > rushing, and command everyone to catch up with you, but we have life, > wife, and children, I am old, I should leave FreeBSD. ??? FYI, I have a life, a job and a wife, too; and while I don't have children, I do have a cat with chronic renal failure which requires constant attention; but I don't use them as excuses to brush off criticism of my work. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no