>>>Also, it's not strictly necessary to release mutexes you've
>>>grabbed if they're being freed, but it's good style to do so.
>>
>>That's assuming you've arranged (out-of-band) that nobody else
>>can be blocking on that lock (I was actually thinking 'spinlock')
>>as should be the case in correct disconnect/destroy logic.
>>Sorry to have omitted that important requirement!
>
>
> If no one can block on it, doesn't that defeat the purpose of it?
As I said, not "strictly" necessary ... except when you happen to
be using those lock analysis tools that report on such issues.
(Or, come to think of it, strict priority scheduling policies in
certain environments.)
Some implementations of blocking locks do things like associating
execution contexts with the locks they hold. (That's more or less
what those tools do.) It'll be used when a higher priority context
happens to need the lock ("priority inversion"). It can get that
lock by using "priority inheritance": loaning its higher priority
to the context currently holding the lock, until it's released.
Depending on how the locking tracks such things, it can be more than
just bad style to free locks that are held ... it can be essential
for preventing oopses, unless there are explicit "destroy this lock"
primitives to scrub out those associations.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
