atomic reference counting primatives.

[Daniel Eischen]

On Mon, 24 May 2004, John Baldwin wrote:

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

You can't use atomic_cmpset() in userland on 386, so
if it is being used in libthr, the machine must be
checked to make sure it will work, otherwise should
fall back to something else...

-- 
Dan Eischen