Thread: Trying to understand hazard pointer implementation

Originally Posted by Codeplug

I believe the Acquire fence goes directly after the label and before the loads.

I may well be wrong, but I think it is not so. (I have not gone on to consider the other changes you've mentioned because I think this first matter affects them, they do not fix this first matter, and this first matter needs to be discussed before we can look further on.)

Before I can explain my thought, the code can be simplified as a result of the change in location of the acquire fence. If the acquire fence is moved directly after the label, then I think we can dispense with the load to local_c0 and local_c1. They're now only checking that in the time from loading local_c0 and local_c1, that no changed have occurred, which is not meaningful - it has no purpose for it does not influence the results of the test.

So, given that change, the reader code looks like this;

Code:

/****************************************************************************/
void *thread_reader( void *thread_argument )
{
  assert( thread_argument != NULL );
 
  reader_start:
  {
    __atomic_thread_fence( __ATOMIC_ACQUIRE );

    if( c0 > c1 )
      printf( "uh-oh! c0 is %llu and c1 is %llu\n", c0, c1 );
  }
  goto reader_start;
 
  return (void *) 1;
}

Now, as I say - I may be completely wrong! but what I think can happen now is that the load barrier occurs, clears the invalidation request queue, and then the read thread pauses; the write thread however continues, does lots of work, and then the read thread resumes.

We see then it is as if there is no load barrier there at all, because we can be immediately after the barrier in any possible state we can be in before the load barrier.

So for example, if we consider the writer thread, it is busy incrementing c0 and c1, and then issuing a store barrier. We then imagine the reader thread has paused after it issued its load barrier, the writer thread - still busy - issues lots of increments. However, since the reader thread is now about the issue its if(), and has not issued another load barrier, it may be that it could for example see lots of updates to c0 and none of the updates to c1. The if() fails - even though we had a load barrier.

This is a race condition, and it is handled by the local_c0 and local_c1 loads.

Here copies are made of c0 and c1. The load barrier is issued. If we see c0 and c1 *have not changed since before the load barrier*, then we *know* we have values in local_c0 and local_c1 which although they may already be out of date, *are correct with regard to each other*.