Re: witness oddity

From: John Baldwin (jhb_at_FreeBSD.org)
Date: 09/10/04

  • Next message: Sean McNeil: "recent multiple posts by me" 
    To: freebsd-current@FreeBSD.org
Date: Fri, 10 Sep 2004 14:50:47 -0400

    On Friday 10 September 2004 02:18 pm, Andrew Gallatin wrote:
    > John-Mark Gurney writes:
    > > Andrew Gallatin wrote this message on Fri, Sep 10, 2004 at 13:18 -0400:
    > > > If I call copyout() holding one of my mutexes, it will always complain
    > > > about a LOR, even if the mutex is freshly initiated:
    > >
    > > Calling copyout while holding a mutex is not allowed... If the page
    > > isn't in memory, it could take many seconds for the page to be swapped
    > > back in during which time your mutex will continue to be held.
    >
    > Thanks.. but that's not really what I asked.
    >
    > I want to know how witness detects a particular just-created mutex as
    > being in a deadlock with the vm map lock.
    >
    > Again, is it because the vm lock is an sx lock? Is there an implicit
    > rule that you can't take an sx lock while holding a mutex (just like
    > you can't take Giant, or sleep?)

    Yes. An sx lock is allowed to be held across a sleep, so if you block on an
    sx lock, the owner of the lock you are waiting on might be asleep. If that
    happens, then your thread won't be able to resume until that other thread is
    woken up and it is basically akin to sleeping with a mutex. Also, if
    copyout() takes a page fault it can sleep, so holding a mutex across copy*()
    is a bad idea anyways. 

    -- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Sean McNeil: "recent multiple posts by me"

    Relevant Pages

    • Re: Locking etc. (Long, boring, redundant, newbie questions)
      ... What is really meant is that depending on the type of mutex a thread is trying to acquire, the thread will either spin or it will sleep waiting for the lock to become available. ...
      (freebsd-hackers)
    • Locking etc. (Long, boring, redundant, newbie questions)
      ... sleep waiting for the lock to become available. ... mutex protects. ... if we spin for so long ...
      (freebsd-hackers)
    • RE: Do you really "sleep" when blocked on a mutex?
      ... means that if a thread is holding a lock, ... Do you really "sleep" when blocked on a mutex? ... sched_wakeup which eventually calls setrunqueue()? ...
      (freebsd-hackers)
    • Re: Recursive mutex that can be waited upon (pthread)
      ... While you can use a mutex to avoid that data is changed, for me having a mutex does not mean that data is not changed, it only means that data is not changed by a different thread. ... My own thread may of course change the data, hence functions I call may want to change the data and if they do so, they must be sure that these changes are atomically, hence they must lock the object and they simply can't rely that I locked the object before -> thus I need recursive locks. ... Then I could as well throw out threads of my code and just use a single thread going through an event queue. ... you have a predicate condition on an invariant. ...
      (comp.programming.threads)
    • Re: problem with CMtex and CSingle lock - WAIT_ABANDONED
      ... See if you ever call TerminateThread. ... Check that you don't close the mutex handle while one thread is holding it. ... you have a "lock hierarchy". ...
      (microsoft.public.vc.language)