Does transition_and_fence really assume TSO?

[David Holmes]

Hi Andrew,

On 3/08/2016 10:04 AM, Andrew Haley wrote:
> Here's an interesting comment:
>
>   static inline void transition_and_fence(JavaThread *thread, JavaThreadState from, JavaThreadState to) {
>     assert(thread->thread_state() == from, "coming from wrong thread state");
>     assert((from & 1) == 0 && (to & 1) == 0, "odd numbers are transitions states");
>     // Change to transition state (assumes total store ordering!  -Urs)
>     thread->set_thread_state((JavaThreadState)(from + 1));
>
> The "assumes total store ordering!" comment is rather alarming.  My
> processor is not TSO.  But as far as I can see, all this really
> requires is single-variable coherency.  Is that right?

That comment is pre-historic. The code does not assume TSO. There is a 
direct, or implicit, full fence between the two stores:

     // Make sure new state is seen by VM thread
     if (os::is_MP()) {
       if (UseMembar) {
         // Force a fence between the write above and read below
         OrderAccess::fence();
       } else {
         // Must use this rather than serialization page in particular 
on Windows
         InterfaceSupport::serialize_memory(thread);
       }
     }

Cheers,
David

> Andrew.
>