Date: Fri, 26 Oct 2001 10:47:34 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: John Baldwin <jhb@FreeBSD.org> Cc: <cvs-all@FreeBSD.org>, <cvs-committers@FreeBSD.org> Subject: Re: cvs commit: src/sys/dev/aac aac.c src/sys/dev/acpica/Osd Osd Message-ID: <Pine.BSF.4.33.0110261046340.16713-100000@herring.nlsystems.com> In-Reply-To: <XFMail.011026020115.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <awr@watson.org> > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.33.0110261046340.16713-100000>