Alan Stern <[EMAIL PROTECTED]> wrote:
>
> Okay, in a separate thread on LKML Andrew Morton has said he doesn't
> really like my approach either. Then what should it be?
>
> Clumsily use different routines for locking the first vs. the
> others in a nested set? (Or clumsily force drivers that want
> to lock more than one device to explicitly acquire and release
> the readlock?)
>
> Or only allow one thread to lock a USB device at any time?
> (That is, don't lock individual devices but only lock the
> entire set of USB devices.)
I'm at a bit of a disadvantage here because I don't know the frequency at
which this lock will be taken, nor the expected hold times.
If it is acceptable to use a non-rw semaphore then you could perhaps do:
take_the_lock()
{
if (sem_holder == current) {
sem_depth++;
} else {
down(&sem);
sem_holder = current;
}
}
drop_the_lock()
{
if (--sem_depth == 0) {
sem_holder = NULL;
up(&sem);
}
}
or something like that.
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
