On Sun, 5 Dec 2004, Stephan Uphoff wrote: > I am wondering if critical sections are overkill for this application > since the interrupt blocking capability is not needed. > > Perhaps a mutex_lock_local, mutex_unlock_local that work on per CPU > mutexes and require the current thread to be pinned to a CPU would be > more appropriate. The functions would have the same functionality as > mutex_lock/mutex_unlock but without using atomic operations. The > "local" mutex would be a clone of the UP sleep mutex and the SMP sleep > mutex and the local mutex could even be used together in any order. > (With working priority inheritance) I think I will try this in my p4 > mutex branch in the next days. > > A "do not preempt" section (Interrupt enabled) would be another > possibility. Silby suggested a UP mutex implementation on SMP to use with pinned threads a month or two ago, and that would work just fine here; I was having similar thoughts also -- while the critical sections are brief, there's really no reason not to allow preemption there. However, the critical section optimizations that I was referring to from John basically do what you suggest second: they implement critical sections via a software "Don't preempt". I don't really mind what the mechanism is, as long as they neither invoke cli/sti or use atomic operations, and it should be possible to easily substitute in the UMA code once my patch is in place. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert_at_fledge.watson.org Principal Research Scientist, McAfee ResearchReceived on Mon Dec 06 2004 - 08:18:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:23 UTC