Date: Fri, 3 Jan 1997 07:07:31 +1100 (EST) From: Julian Assange <proff@iq.org> To: archie@whistle.com (Archie Cobbs) Cc: hackers@freebsd.org Subject: Re: divert code not thread/smp compatible Message-ID: <199701022007.HAA12208@profane.iq.org> In-Reply-To: <199701021936.LAA26380@bubba.whistle.com> from Archie Cobbs at "Jan 2, 97 11:36:06 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Is this an acceptable trick in the FreeBSD kernel, passing parameters
> > > with global variables?
> > >
> > > -Julian <proff@iq.org>
>
> My only excuse is that at the time I started writing the divert code,
> it wasn't planned on being checked in to the main branch, but instead
> was going to be a patch to be applied locally... so I tried to keep
> the patch as small as possible... and as a result committed some
> non-esthetically pleasing programming in the process... :-)
>
> Any suggestions on the best way to properly threadify this?
>
> Thanks,
> -Archie
Well, I looked at threading/locking issues in netinet/* generally and
have come to view the chances of seeing more than one thread in anything
close to the bsd44 inet code is zero. The whole thing is locked by
a few fat, totally non-granular splnet()s.
While we are on the subjects of locking, I notice a distinct lack
of atomic test-and-set or test-and-inc instructions for struct
usage counts (which are instead relying on non-atomic C). Is there
such an existing kernel macro that does:
int
tas(slock_t *m)
{
slock_t res;
__asm__("xchgb %0,%1":"=q" (res),"=m" (*m):"0" (0x1));
return(res);
}
-Julian <proff@iq.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701022007.HAA12208>