Subj : Re: Memory visibility and MS Interlocked instructions
To   : comp.programming.threads
From : Chris Thomasson
Date : Fri Aug 26 2005 06:32 pm

> What confuses me is that here only the writer needs to take an action to
> guarantee that readers will see things in the proper order, where my
> understanding had been that the reader, too, would have to take some 
> action
> before reading iValue and fValueHasBeenComputed to ensure that it didn't
> get a stale value for one or both.


>   BOOL volatile fValueHasBeenComputed = FALSE;
>
>   void CacheComputedValue()
>   {
>     if (!fValueHasBeenComputed)
^^^^^^^^^^

Relying on compiler to inject a data-dependant acquire, hoist, 'whatever' 
barrier for volatile loads is probably not a good practice...

;)


>     {
>       iValue = ComputeValue();
>       InterlockedExchange((LONG*)&fValueHasBeenComputed, TRUE);
^^^^^^^^^^

IMO, the atomic exchange has to ensure that fValueHasBeenComputed is 
atomically set to TRUE "after" ComputeValues(...) 's effects are made 
visible. The ordering for the writer would have to go something like this:

  1( call init_func ) => 2( set atomic_flag )

The state transition would require a release barrier in order to ensure that 
state 1's effects are fully visible to state 2. This kind of brings up 
another question:


Will InterlockedExchange ensure that the ( fValueHasBeenComputed == TRUE ) 
condition is not made visible "before" ComputeValues(...)'s effects are made 
visible? Humm... This example of DCL "may" be busted on the writer's end as 
well...




> Obviously I'm missing something.

Na.

:)

.