Date: Fri, 3 Jun 2005 19:45:43 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: Seb <sebastien.b@swissinfo.org> Cc: freebsd-usb@freebsd.org Subject: Re: usbd_bulk_transfer returns 1 (USBD_IN_PROGRESS) ?! Message-ID: <200506031945.44972.hselasky@c2i.net> In-Reply-To: <200506031535.53126.sebastien.b@swissinfo.org> References: <200505252120.22408.sebastien.b@swissinfo.org> <200505281531.14351.hselasky@c2i.net> <200506031535.53126.sebastien.b@swissinfo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 03 June 2005 15:35, Seb wrote:
> On Saturday 28 May 2005 15:31, Hans Petter Selasky wrote:
> > On Friday 27 May 2005 13:31, Seb wrote:
> > > But I didn't fix it with mutexes, I used semaphores instead.
> > > I initialize a semaphore with a value equal to 1 and then, before the
> > > USB transfers, I do :
> >
> > while(entered)
> > {
> >
> > > mtx_unlock(&Giant);
> > > sema_wait(&sc->usb_tx_sema);
> > > mtx_lock(&Giant);
> >
> > }
> > entered = 1;
> >
> > > And after the USB transfers :
> > > sema_post(&sc->usb_tx_sema);
> >
> > entered = 0;
>
Because there might be a race here. Two threads can call "sema_wait()", and
when you call "sema_post()" both threads will wake up. Then the first thread
will run until the USB code sleeps, and the the second thread will enter into
the same USB code causing unpredictable behaviour.
> I'm afraid I don't understand why I should do that.
> Moreover, if the functions are never called concurrently, the semaphore
> value will never go down...
>
> > > Is this OK ?
> >
> > I think it is better you use "sx_xlock", "sx_xunlock" and "sx_init".
> > See "man sx".
>
> What would be the difference with mutexes ? Only so that I can sleep while
> holding the lock ?
see:
cat /sys/kern/* | more
Type "/_sx_xlock" and press enter. sx-locks allow what is really not a good
idea, and that is to sleep while holding a lock. Do you see what can happen
if one doesn't exit locks while sleeping:
thread_1:
lock A;
sleep();
unlock A;
thread_2:
lock A;
/*
* this code will never be reached if
* one doesn't exit lock "A" before
* sleeping
*/
wakeup();
unlock A;
> Is calling sx_xlock() safe while holding Giant?
Yes.
>
> > If you do things via callback you can remove "sc->tx_queues[]" and
> > associated functions.
>
> No, these are also part of Conexant's proprietary protocol.
Aren't the queues just doing first in first out? You fix some headers and then
put the packet onto the queue? But instead of putting the packet onto the
second queue you ought to send the packets out right away?
--HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506031945.44972.hselasky>