Steven Rostedt wrote:
On Sat, 2005-04-16 at 09:05 -0400, john cooper wrote:
Sven Dietrich wrote:
[...]
This one probably should be a raw_spinlock.
This lock is only held to protect access to the queues.
Since the queues are already priority ordered, there is
little benefit to ordering -the order of insertion-
in case of contention on a queue, compared with the complexity.
The choice of lock type should derive from both the calling
context and the length of time the lock is expected to be held.
In this case, I don't think time matters for choice of lock. Time
matters to keep it short since it does need the raw_spin_lock. This
lock is part of the whole locking scheme, and would be similar to not
using raw_spin_locks in the implementation of rt_mutex. Well, not
exactly the same, but if we want the fusyn code to use the same code as
rt_mutex for PI, then it will need to be a raw_spin_lock.
Ok, I was missing the context -- it does need to be a raw lock.
Is the scope of this lock limited to manipulating the list or
is it held to serialize other operations?
-john
--
[email protected]
-
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]
