View topic - synchronization issue usb-ddk <-> resmgr framework

synchronization issue usb-ddk <-> resmgr framework

Read-only archive of qnx.ddk (Writing device drivers for scanners, video card, optical mouse, etc) at inn.qnx.com

synchronization issue usb-ddk <-> resmgr framework

Postby rgallen » Wed Mar 10, 2004 8:08 pm

I have a synchronization issue that I can't come up with a
good solution for. Since this appears to be somewhat endemic
to USB and resmgr framework, I was wondering if there is a
general solution.

Assumptions (any of these invalid ?):

1. resmgr_detach will not block when a io callback is
active, even when _RESMGR_DETACH_ALL flag is specified.
resmgr_detach *does* block for connect (but not IO)
callbacks.

2. The usbd code that calls the user supplied removal callback
deallocates the memory that was specified during the call
to usbd_attach() *after* calling the clients removal
callback.

OK, here is the scenerio.

1. One of my client read threads (io_read callback), is
sleeping on some buffers that are allocated to pointers
that reside in the area provided to usbd_attach.

2. The USB cable is removed.

3. The removal callback is dispatched.

4. The removal callback does a broadcast on the addresses
that the client thread (from 1) is sleeping on; then...

5. resmgr_detach is called (with the _RESMGR_DETACH_ALL flag
set). This doesn't block (assumption 1).

6. Due to the fact that the USB DDK client thread that
executes the removal callback is of a higher priority than
the client priority driver threads of the io_* callbacks,
the removal thread frees all the memory associated with
the client buffers, and returns.

7. The USB DDK client library then frees the entire structure
that was reserved with the usbd_attach() call.

8. Client thread now wakes up (from the broadcast in 4), and
checks a status field inside the area allocated via
usbd_attach(). Here is the problem. This area is no
longer valid as it has been freed.

How does one get around this issue cleanly ? It seems to me
that if resmgr_detach, did block (due to the fact that an IO
callback was active), then everything would be cool, since
the broadcast would guarantee that the io thread would awake
before the removal thread had smoked the memory. It would
check that status field in the (still valid) memory area,
and return immediately with an error (since a flag there
would indicate the the device had been removed).

Of course, I could come up with some scheme of my own to do
this, but I guess I'm not quite sure why outstanding IO
operations do not cause resmgr_detach to block until they
have completed (with the responsibility of client code to
insure that the operations do complete - in my case because
I deliberately unblock them in the removal callback).
rgallen
QNX Master
 
Posts: 671
Joined: Thu Jul 11, 2002 6:48 pm

Return to qnx.ddk

Who is online

Users browsing this forum: No registered users and 1 guest

cron