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

That is, if you have a shared memory object, all safe readers/writers are
using some form of interlock of which the stX_c is one aspect (the CIA bridge
to memory is another aspect on, say, a PC164). So you don't have to use an MB,
because the the stX_c should guarantee that consistency.

Where's yer green book? It oughta say (although I've found it somewhat vague
on occasion).

On Sun, 13 Aug 2000, Jason R Thorpe wrote:

> Folks...
> 
> I noticed this in the context of the Alpha port, but I think it's
> a potential issue for all MP-capable arch's.
> 
> On the Alpha, you're supposed to issue a memory barrier to ensure
> that other "processors" see the changes you've made to a memory
> location -- basically, you drain the write buffer.  The "processor"
> may be an I/O device (such as a disk controller, DMA mapper, etc.)
> 
> What I'm not entirely clear on is if this is strictly necessary for
> other CPUs on the system.  I was under the impression that this is
> necessary when I wrote the Alpha simple lock primitives, issuing
> an MB after the stl_c completed successfully.
> 
> While doing some hacking in the pmap module, it occurred to me that
> this would be a good idea for PTEs, too.  But then I thought -- geez,
> where does it end?  Do you issue an MB after frobbing with any random
> linked list structure?  Etc.
> 
> I would appreciate some input on this -- I haven't yet read the
> architecutre manual after thinking about this... and, indeed, it
> may not be much of an issue, if a global data structure is protected
> with locks, and those locks, when released, perform the necessary
> memory barriers...
> 
> Anyway, I wanted to bring it up.
> 
> -- 
>         -- Jason R. Thorpe <thorpej@zembu.com>
>