> This patch fixes a problem with my recent set of locking changes for USB. > The problem is that rw-semaphores don't have the semantics I need. I need > something where, if the semaphore is locked for reading and a writer is > waiting for the lock, another reader will be granted a readlock > immediately. That's because there are several places where a thread > holding the readlock will acquire the readlock again, in a nested or > recursive fashion. If a writer is waiting for the first readlock to be > released, the standard semantics will yield deadlock.
Is there any chance that a writer will wait for ever because readers never stop coming? Another way of doing this kind of locking is to say that if you (a certain task) already have the lock then you can get it again, but no-one else can. That way starvation is avoided. Is it important to have several different readers hold the lock at the same time? But maybe you did it the way I suggest (...makes note to self to actually read the patch...)... Ciao, Duncan. ------------------------------------------------------- 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
