From owner-cvs-all Fri Oct 26 2: 1:45 2001 Delivered-To: cvs-all@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id F3A7037B409 for ; Fri, 26 Oct 2001 02:01:38 -0700 (PDT) Received: (qmail 69471 invoked from network); 26 Oct 2001 09:01:17 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Oct 2001 09:01:17 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011026094417.B549-100000@salmon.nlsystems.com> Date: Fri, 26 Oct 2001 02:01:15 -0700 (PDT) From: John Baldwin To: Doug Rabson Subject: Re: cvs commit: src/sys/dev/aac aac.c src/sys/dev/acpica/Osd Osd Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 26-Oct-01 Doug Rabson wrote: > On Thu, 25 Oct 2001, John Baldwin wrote: > >> jhb 2001/10/25 23:32:21 PDT >> >> Modified files: >> sys/dev/aac aac.c >> sys/dev/acpica/Osd OsdSchedule.c >> sys/dev/amr amr.c >> sys/dev/mly mly.c >> sys/kern subr_taskqueue.c >> sys/sys taskqueue.h >> Log: >> Add locking to taskqueues. There is one mutex per task, one mutex per >> queue, and a mutex to protect the global list of taskqueues. The only >> visible change is that a TASK_DESTROY() macro has been added to mirror >> the TASK_INIT() macro to destroy a task before it is free'd. >> >> Submitted by: Andrew Reiter > > Thats a lot of mutexes. Wouldn't it be better to use a mutex pool for > tasks? That would avoid the need for TASK_DESTROY too. Tasks were intended > to be extremely lightweight, small objects with a stable ABI. This also > forces them to depend on the mutex ABI. Well, one thought I had was that the queue lock might be able to protect all the tasks on that queue. I think that works but am not sure. I think it would satisfy the current locking done on tasks at least. Does this sound feasible? Hmm. The only variable that's potentially manipulated while the task is on a queue is the pending count, and the queue lock can protect that. This assumes that if a task is not on a queue only one thread references it in which case it can do with it as it pleases w/o needing any locks until it puts it on the queue, at which point it must stay read only until it is dequeue'd. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message