Re: atomic reference counting primatives.

From: Bruce Evans (bde_at_zeta.org.au)
Date: 05/21/04

  • Next message: Max Laier: "Re: atomic reference counting primatives."
    Date: Fri, 21 May 2004 13:45:32 +1000 (EST)
    To: Julian Elischer <julian@elischer.org>
    
    

    On Thu, 20 May 2004, Julian Elischer wrote:

    > 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.

    Now we know that a generic reference counter would be even better for
    pessimizing FreeBSD than was first thought, since on P4's locked
    instructions are very expensive. See the thread about bridging. A
    pessimization by a factor of 2 or so has been achieved using little
    more than normal locking, since there are lots of lock/unlock pairs
    per packet and each lock and unlock takes hundreds (?) of cycles for
    the bus lock part and very little else. General atomic counters of
    any sort would take about half as lock as a lock/unlock pair (since
    they only need 1 lock, but would always needed it even if running in
    a locked region). The pessimizations from them could be broken using
    algorithms that don't need fine-grained locking.

    Bruce
    _______________________________________________
    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: Max Laier: "Re: atomic reference counting primatives."

    Relevant Pages

    • Re: How to do proper locking
      ... >> lock across malloc, so your allocation code isn't safe. ... while you bump the reference count, ... PROC_LOCKwhile doing crhold(). ... > - setting up timers. ...
      (freebsd-hackers)
    • Re: [PATCH] tipc: checking returns and Re: Possible Circular Locking in TIPC
      ... Jarek Poplawski wrote: ... until and unless the latter function has returned a valid reference. ... Is it OK to call it without the lock ... One reference entry points to a subscription instance, ...
      (Linux-Kernel)
    • Re: [PATCH] tipc: checking returns and Re: Possible Circular Locking in TIPC
      ... Jarek Poplawski wrote: ... IMHO lockdep ... until and unless the latter function has returned a valid reference. ... Is it OK to call it without the lock ...
      (Linux-Kernel)
    • Re: Threads - why isnt a whole object locked when ...?
      ... reference to A1 on a lock inside some other method (which may very- ... it's not guaranteed to cause dead-lock. ... taken in a different sequence from the code using the "this" reference as the locking object. ... What would be the best way to protect that data? ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: Core i7 CMPXCHG-performance
      ... "find an object and increment its reference ... > a lock anyway. ... synchronization between the constructing thread and the other threads ... It does not matter if one uses locks or atomics to mutate the counter; they both have the same problems. ...
      (comp.programming.threads)