Re: atomic reference counting primatives.
From: Bruce Evans (bde_at_zeta.org.au)
Date: 05/21/04
- Previous message: M. Warner Losh: "Re: atomic reference counting primatives."
- In reply to: Julian Elischer: "atomic reference counting primatives."
- Next in thread: Max Laier: "Re: atomic reference counting primatives."
- Reply: Max Laier: "Re: atomic reference counting primatives."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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"
- Previous message: M. Warner Losh: "Re: atomic reference counting primatives."
- In reply to: Julian Elischer: "atomic reference counting primatives."
- Next in thread: Max Laier: "Re: atomic reference counting primatives."
- Reply: Max Laier: "Re: atomic reference counting primatives."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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: How to do proper locking
... >> drop the proc lock, so that lock is only held for a very short period of ...
You then have your own reference to the cred structure that is ... > destroying an object
while the refcount is non-zero. ... > if one routine sleeps, then any callers
of this routine must sleep too. ... (freebsd-hackers) - Re: Is garbage collection here yet?
... instead are made by asking the container object for its wherabouts. ... the
container passes back a reference. ... I used it" with a time stamp. ...
get killed if anything came along and established a new lock). ... (comp.lang.tcl)