Yony Yossef wrote:

        Something is still unclear. All my locks are MTX_DEF type, which
        sleepable, including the one specified in the crash report
        (MTNIC state
        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 :-)


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.


freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to