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]"
