Howard Chu wrote:
But why does A take the mutex in the first place? Presumably because it
is about to execute a critical section. And also presumably, A will not
release the mutex until it no longer has anything critical to do;
certainly it could hold it longer if it needed to.
Suppose A is pulling job requests off a queue.
A takes the mutex because it is going to modify data protected by the
mutex. It then gives up the mutex when it's done modifying the data.
If A still needed the mutex, why release it and reacquire it, why not
just hold onto it? The fact that it is being released is significant.
Suppose A then pulls another job request off the queue. It just so
happens that this job requires touching some data protected by the same
mutex. It would need to take the mutex again.
A doesn't necessarily know what data the various jobs will require it to
access, so it doesn't know a priori what mutexes will be required.
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]