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>