Re: atomic reference counting primatives.
From: John Baldwin (jhb_at_FreeBSD.org)
Date: 05/24/04
- Previous message: Garance A Drosihn: "Third "RFC" on on pkg-data ideas for ports"
- In reply to: Garance A Drosihn: "Re: atomic reference counting primatives."
- Next in thread: Daniel Eischen: "Re: atomic reference counting primatives."
- Reply: Daniel Eischen: "Re: atomic reference counting primatives."
- Reply: Daniel Eischen: "Re: atomic reference counting primatives."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: freebsd-arch@FreeBSD.org Date: Mon, 24 May 2004 10:38:19 -0400
On Friday 21 May 2004 08:44 pm, Garance A Drosihn wrote:
> At 1:56 PM -0700 5/20/04, Julian Elischer wrote:
> >This has been raised before but I have come across uses for
> >it again and again so I'm raising it again. JHB once posted
> >some atomic reference counting primitives. (Do you still have
> >them John?) Alfred once said he had some somewhere too, and
> >others have commented on this before, but we still don't seem
> >to have any.
>
> Btw, does this thread have anything to do with the present
> buuldworld-breakage for sparc64? I notice the compile-time
> errors are something like:
No.
> /usr/src/lib/libthr/thread/thr_cancel.c: In function `testcancel':
> /usr/src/lib/libthr/thread/thr_cancel.c:123: warning: passing
> arg 1 of `atomic_cmpset_int' from incompatible pointer type
>
> My guess is that this is related to Mike's change to "Make libthr
> async-signal-safe without costly signal masking. [...etc...]".
>
> This breakage underlines one reason that it would be mighty
> convenient to have some "official" set of primitives. It is
> one thing if a developer has to roll-their-own solution for
> i386, but somewhat more challenging if that solution has to
> work across a half-dozen different hardware platforms.
atomic_cmpset() is an "official" primitive. The problem is that Mike is using
an enum and assuming that all enum's are ints which is not necessarily true.
The code should perhaps use an int with #define's instead to guarantee that
the variable is an int and not a short, char, or long.
-- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org _______________________________________________ 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: Garance A Drosihn: "Third "RFC" on on pkg-data ideas for ports"
- In reply to: Garance A Drosihn: "Re: atomic reference counting primatives."
- Next in thread: Daniel Eischen: "Re: atomic reference counting primatives."
- Reply: Daniel Eischen: "Re: atomic reference counting primatives."
- Reply: Daniel Eischen: "Re: atomic reference counting primatives."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: atomic reference counting primatives.
... On Friday 21 May 2004 08:44 pm, Garance A Drosihn wrote: ... but somewhat
more challenging if that solution has to ... the variable is an int and not a short,
char, or long. ... (freebsd-arch) - Re: mergemaster feature suggestion...
... Garance A Drosihn said: ... but it is much more challenging to
come up with a solution ... You can not have installworld just blindly ... (freebsd-current)