On Mon, 14 Aug 2000, Jason R Thorpe wrote:

> On Sun, Aug 13, 2000 at 10:52:17PM -0700, Matthew Jacob wrote:
> 
>  > I don't think you need to issue an MB if the stl_c is being used. This was the
>  > conclusion the FreeBSD list came to after pondering whether you could use a
>  > stl_c to avoid partial word race conditions with something like the EEPRO (it
>  > was decided that this was okay, and that an MB after a stX_c was not needed).
> 
> Well, after disassembling OSF/1's simple lock routines, they clearly
> are using MBs after stl_c, and Brown Book (newer version of Green Book :-)
> doesn't say anything about stl_c performing a barrier.  stl_c merely
> interacts with the "locked" register in the memory controller, as far
> as I can tell.

Huh. Well, you never know... New book? I guess I'll hit amazon.. or is it only
on FatheadedFormerCLBOOKS.com?

> 
> In any case, my question was mostly about things which are not using
> ldl_l/stl_c, but rather other global data structures.  Like linked
> lists, PTEs, VM objects, etc. which are generally protected with
> locks, which would then have to ensure coherency of THOSE structures
> by issuing an MB.

Well, if your ldx_l/stX_c locking is using MBs, then, err, umm, you're
covered.

I think what you might be concerned about is read coherency then, right? That
is, you have the locks as writelocks, but you are updating the structures with
one CPU but another one gets and inconsistent read because of the lack of an
MB?

Gee, I don't think this is a solveable problem if the CPUs aren't cache
coherent.

-matt