Date: Mon, 15 May 2000 09:40:44 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Chuck Paterson <cp@bsdi.com> Cc: Arun Sharma <adsharma@sharmas.dhs.org>, freebsd-arch@freebsd.org Subject: Re: A new api for asynchronous task execution Message-ID: <Pine.BSF.4.21.0005150929280.47945-100000@salmon.nlsystems.com> In-Reply-To: <200005141731.LAA04793@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 May 2000, Chuck Paterson wrote:
> While writing up this I noticed a trivial bug
>
> taskqueue_enqueue(struct taskqueue *queue, struct task *task)
> {
> int s = splhigh();
>
> /*
> * Count multiple enqueues.
> */
> if (task->pending) {
> task->pending++;
> return; <---- really need a splx before this
Well spotted, thanks.
> }
>
>
> }
> }I agree that the queue should have a mutex to protect itself. Since we
> }haven't finalised the api for mutex locking (we will almost certainly use
> }the BSD/OS one), I can't add anything yet but I will when the new SMP
> }work starts.
>
> FYI, the current BSD/OS mutex's have a string associated
> with them, ie there name. This name is used for debugging (checking
> lock order) and perhaps for blowing locks open at panic time.
> Mutex's which aren't part of a group of a unique name, an example
> of this might be "ipqlock". For mutex's which are all really the
> same they share the same name such as "vnode interlock". There is
> also the issue of what flags are passed in to initialize the mutex,
> and for that matter flags used in acquiring the mutex. I guess I
> should for now just point out some of the issues.
>
> 1) It would be useful to have meaningful name associated with
> a mutex when initializing the mutex associated with a taskqueue.
>
> 2) There are flags needed with initializing the mutex associated
> with a taskqueue.
>
> 3) When acquiring the mutex associated with a queue it wants to
> in general not be of type M_SPIN, but sometimes it will.
This makes sense. I didn't think too hard about the needs of
mtx_init() when writing this but it should work to add these arguments to
taskqueue_init().
>
> 4) As proposed now the mutex protecting the queue often does not
> want to be held while the enqueueing function is called. This is
> particularly true if the enqueueing function may cause an immediate
> context switch.
Right. In the spl version similarly, I don't want to call the task at
splhigh().
>
> 5) Even the taskqueue_run really wants to just know what
> type of mutex is present.
>
> In some ways the implementation of taskqueue_enqueue() is
> not as important to get right from the start as the calling sequence
> to it. There are almost certainly going to be lots more users of
> the swi taskqueue than anything else and changing the few actual
> implementation of the enqueuer function and init function seem like
> not a big deal.
Thats my view exactly. I want to fix the calling convention of
taskqueue_enqueue() and the layout of struct task since those are the main
features which most users of the api are exposed to.
The implementation details of struct taskqueue are less important. In
fact, I think it should be possible to hide the definition of struct
taskqueue completely by moving it out of the header. That would isolate
any callers from implementation changes quite neatly.
>
> I have included just some sketches of how you could deal
> with some of this. Just something to think about
>
> The following is very slightly slower because the type of
> mutex is not known at compile times, but it makes it possible
> to not have to totally change to model.
Thanks for spending the time to look at this stuff in detail.
--
Doug Rabson Mail: dfr@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 20 8442 9037
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" 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.21.0005150929280.47945-100000>