From owner-cvs-all Fri Oct 26 2:49: 1 2001 Delivered-To: cvs-all@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 0E88337B406; Fri, 26 Oct 2001 02:48:51 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 15x3bd-000Psk-0Y; Fri, 26 Oct 2001 10:48:49 +0100 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9Q9lY716729; Fri, 26 Oct 2001 10:47:34 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 26 Oct 2001 10:47:34 +0100 (BST) From: Doug Rabson To: John Baldwin Cc: , Subject: Re: cvs commit: src/sys/dev/aac aac.c src/sys/dev/acpica/Osd Osd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Fri, 26 Oct 2001, John Baldwin wrote: > > 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. I think that sounds perfectly reasonable. After initialisation, the only part of a task which changes is the STAILQ_ENTRY() which is effectively owned by the queue and covered by the queue's mutex. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message