Date: Thu, 25 Sep 2003 20:20:59 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: David Xu <davidxu@FreeBSD.org> Cc: threads@FreeBSD.org Subject: Re: THR and KSE platform support (again) Message-ID: <Pine.GSO.4.10.10309252013560.27808-100000@pcnet5.pcnet.com> In-Reply-To: <200309260806.57365.davidxu@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[CC list trimmed, sent to threads@]
On Fri, 26 Sep 2003, David Xu wrote:
> On Friday 26 September 2003 06:57, Daniel Eischen wrote:
> > > I have some ideas may not related to this topics:
> > > On alpha, we need Memory Barrier for kse_crtical_enter.
> > > Because we always have following access pattern:
> > > kse_critical_enter();
> > > KSE_SCHED_LOCK(curthread->kse, curthread->kse->k_kseg);
> > > if there is no Memory barrier in kse_critical_enter, then
> > > read ahead of curthread->kse by CPU is wrong.
> > > I have a small patch for kcd_critical_enter for alpha.
> >
> > I thought atomic_{load,store}_{acq,rel} would give us
> > appropriate memory barriers. Or are we not always using
> > these functions where we should be?
> >
> kcb_critical_enter on alpha is not using atomic instructions,
> out of order read/write makes kcb_critical_enter not work
> on SMP.
Yes, I see what you mean. If it is isolated to MD
functions like kcb_critical_enter() I would either
use the atomic_ functions, or add the memory barrier
directly to those functions. Hopefully, we can keep
MI parts free of memory barriers.
--
Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309252013560.27808-100000>