Re: [Linux-ia64] spin_unlock() problem

[Jes Sorensen <jes@wildopensource.com>]

>>>>> "David" = David Mosberger <davidm@napali.hpl.hp.com> writes:

David> *a is guaranteed to have the value "foo" when *b observes bar.
David> spin_unlock() has release semantics and that ensures that all
David> subsequent (in program order) memory operations are observed
David> after the store with release semantics.

Hi David,

Back to getting a sore head from this one ;-(

Thanks for the book reference, I went and read it and then went on to
the Intel IA-64 Architecture Software Developer's Manual, vol #1. I
only have an old version 1.1 dated July 2000, so it's possible that
there is an updated version out with further clarifications.

Quoting section 4.4.7 "Memory Access Ordering", 2nd paragraph, it says
" .... Release data accesses guarantee that all previous data accesses
are made visible prior to being made visible themselves." The way I
understand that, it is possible that a store performed after an st.rel
may become visible prior to the st.rel, like in this example:

  st [r2] = r32
  st.rel [r3] = r33
  st [r4] = r34

In other words we are only guarantied that [r2] is valid when [r3]
appears but have no guarantie that [r4] doesn't show up on the bus
prior to [r3]?

Sorry for continuing to pester you about this one, it's the only
explanation I can find for the problems some people have been seeing
for tty->count getting messed up in some cases (it is always modified
while holding a spin lock).

Cheers,
Jes