Problem solved :-) Thank you very much for your patience Kris.. On Tue, Jul 15, 2008 at 5:14 PM, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> Yony Yossef wrote: > >> >> Something is still unclear. All my locks are MTX_DEF type, which >> means >> sleepable, including the one specified in the crash report >> (MTNIC state >> semaphore). >> This crash happens when I try to call bus_resource_alloc_any for >> a SYS_REQ >> which is trying to obtain the second lock (ACPI root bus). How >> come my >> MTX_DEF lock is being treated as as non-sleepable? >> >> >> MTX_DEF locks *are* non-sleepable :-) >> >> Kris >> >> Good news :-) >> Yet the documentation is confusing me: >> man pages say: >> MTX_DEF Default mutexes will always allow the current thread to be >> suspended to avoid deadlock conditions against >> interrupt >> threads. The implementation of this lock type may spin >> for a while before suspending the current thread. >> and in mutex.h: >> /* >> * Mutex types and options passed to mtx_init(). MTX_QUIET and MTX_DUPOK >> * can also be passed in. >> */ >> #define MTX_DEF 0x00000000 /* DEFAULT (sleep) lock */ >> #define MTX_SPIN 0x00000001 /* Spin lock (disables interrupts) */ >> #define MTX_RECURSE 0x00000004 /* Option: lock allowed to recurse */ >> #define MTX_NOWITNESS 0x00000008 /* Don't do any witness checking. */ >> #define MTX_NOPROFILE 0x00000020 /* Don't profile this lock */ >> What does the "DEFAULT (sleep) lock" comment near MTX_DEF means? >> And which ones are sleepable?.. I guess I'm missing something here. >> > > "sleep mutex" means that the mutex holder may be put to sleep by the kernel > while the mutex is held by another process (if the lock holder is running > then it will spin, though). It is in contrast to "spin" mutexes that always > spin forever while the lock is held, even when it might be inefficient for > them to do so because the lock holder is no longer running after the CPU > context switched to another process before it released the lock. > > This describes the behaviour of the mutex while it is waiting to acquire a > lock. > > "sleepable" vs "non-sleepable" locks means what it is legal for your code > to do while holding a mutex and doesn't relate to the internal > implementation of the lock. > > This describes what it is legal for your code to do once it has acquired > the lock. > > Kris > > _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
