On Thursday 17 May 2007 16:35, Alan Stern wrote: > On Thu, 17 May 2007, Hans Petter Selasky wrote: > > If you need to do Async stuff, then you have to do it in a separate > > thread or in a so-called task-queue. Else you are in for great trouble! > > That was the big "sin" in the old USB stack on FreeBSD: Calling > > synchronous USB callbacks from everywhere, like ioctl/read/write - > > callbacks. > > > > Is that a problem on Linux also? > > It's hard to answer; your use of terminology is peculiar. The word > "synchronous" does not mean capable of blocking; it means that the > routine waits until a result is received. It is not directly related > to whether the routine runs in a process context (which can sleep) vs. > an atomic context (one which isn't allowed to sleep).
I meant blocking USB transfers, there. For example when you want to do a control transfer and wait for it to finish. > > Referring to a callback as "synchronous" doesn't make sense. A > callback doesn't send a message -- it _receives_ a message -- and hence > it doesn't need to wait for any result. Right. > > In Linux, the USB callbacks are generally atomic. Does that answer > your question? Yes. So you protect the callback with a lock to make it atomic? > > > On Linux I see no locks used in the USB drivers, so they are solely > > protected by interrupt-level mechanisms. > > That's an awfully strange thing to say. No locks used in the USB > drivers? Good lord, they are full of locks! Semaphores, mutexes, > spinlocks -- you name it, it's in there. Ok, Ok. I'm not the Linux expert. > > > My rule is that: Synchronous or blocking calls _must_ happen in a config > > thread that you can wait for. Else asynchronous calls on pre-allocated > > transfers can happen anywhere. > > What distinguishes a "config" thread from any other kind of thread? > What distingishes threads you can wait for from threads you can't wait > for? > > What's wrong with a config thread that you can't wait for making a > blocking call? Who cares if you can't wait for it? -- the thread will > still carry out the call okay. You can use any thread you like, as long as you make sure it is gone before the detach routine of the USB device in question returns. > > > The problem clearly appears on Linux SMP because: > > What problem? Or should I say, Which problem? > > > a) No locks are in the USB drivers (then they must be all so-called > > "Giant" locked) > > You must be living in some sort of fantasy land if you really believe > this. Or else you're looking at a version of Linux from 8 years ago. > > > b) You don't pre-allocate transfers, resulting in synchronous/blocking > > calls everywhere, and no-one thinks about what can happen then :-) > > Your reasoning is illogical. Why does allocation have to be blocking? Memory allocation is blocking in that way it might have to flush out memory pages to a harddisk, before those pages can be allocated by something in the kernel. Of course there exists no-wait options that you can pass to "malloc", but I wouldn't rely too much on those flags unless you are allocating from a pre-defined memory pool, where you know that there is memory reserved for you. > In code paths which can't block, we do non-blocking late allocation. > And we do think about what can happen. Good. --HPS ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
