Re: atomic reference counting primatives.

From: M. Warner Losh (imp_at_bsdimp.com)
Date: 05/21/04

  • Next message: Bruce Evans: "Re: atomic reference counting primatives." 
    Date: Thu, 20 May 2004 20:54:03 -0600 (MDT)
To: julian@elischer.org

    In message: <Pine.BSF.4.21.0405201340590.72391-100000@InterJet.elischer.org>
                Julian Elischer <julian@elischer.org> writes:
    : This has been raised before but I've come across uses for it again and
    : again so I'm raising it again.
    : JHB once posted some atomic referenc counting primatives. (Do you still
    : have them John?)
    : Alfred once said he had soem somewhere too, and other s have commentted
    : on this before, but we still don't seem to have any.
    :
    : every object is reference counted with its own code and
    : sometimes it's done poorly.
    :
    : Some peiople indicated that there are cases where a generic refcounter
    : can not be used and usd this as a reason to not have one at all.
    :
    : So, here are some possibilities..
    : my first "write it down without too much thinking" effort..
    :
    : typedef {mumble} refcnt_t
    :
    : refcnt_add(refcnt_t *)
    : Increments the reference count.. no magic except to be atomic.
    :
    :
    : int refcnt_drop(refcnt *, struct mutex *)
    : Decrements the refcount. If it goes to 0 it returns 0 and locks the
    : mutex (if the mutex is supplied)..

    What prevents refcnt_add() from happening after ref count drops to 0?
    Wouldn't that be a race? Eg, if we have two threads:

            Thread A Thread B

            objp = lookup();
    [1] refcnt_drop(&objp->ref, &objp->mtx);
    [2] refcnt_add(&obj->ref);
                                            BANG!

    If [1] happens before [2], then bad things happen at BANG! If [2]
    happens before [1], then the mutex won't be locked at BANG and things
    is good. Thread A believes it has a valid reference to objp after the
    refcnt_add and no way of knowing otherwise.

    Is there a safe way to use the API into what you are proposing?

    Warner
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Bruce Evans: "Re: atomic reference counting primatives."

    Relevant Pages

    • Unexpected release of named mutex
      ... I have a mutex that releases while I am still holding a reference to ... Dim singleInstance As Threading.Mutex = Nothing ... Application.ProductName & ".SingleInstance", goodToGo) ... Silly me, thinking that I could keep a reference to an object by, uh, ...
      (microsoft.public.dotnet.framework)
    • Re: [PATCH RFD] alternative kobject release wait mechanism
      ... There is no reason to hold reference to it. ... you grab the mutex excluding its removal and verified it's still there. ... It also wakes up all threads that are blocked trying to lock the ...
      (Linux-Kernel)
    • Re: WaitForSingleObject() will not deadlock
      ... You keep talking about needing to know the reference count. ... algorithm that uses a recursive mutex that cares in the slightest what the reference count ... attempts to lock appears to be isomorphic to a recursive lock, ... cycle detection until you reach the end of the list, ...
      (microsoft.public.vc.mfc)
    • Re: Library design for canceling a running operation?
      ... The main part of the public api is very similar to normal file I/O: ... cancel a running operation. ... thread that's performing the operation has a reference. ... The operation object contains a mutex, condition variable, and any ...
      (comp.programming.threads)
    • Re: [PATCH RFD] alternative kobject release wait mechanism
      ... Tejun Heo wrote: ... Here's an example where immediate-detach cannot be implemented. ... There is no reason to hold reference to it. ... I probably have over simplified it but using both mutex and reference ...
      (Linux-Kernel)