Messages in this thread | | | Date | Sat, 16 Apr 2005 10:51:54 -0400 | From | john cooper <> | Subject | Re: FUSYN and RT |
| |
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
-- john.cooper@timesys.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |