[cpp-threads] Yet another visibility question

[Raul Silvera]

Thanks, Ben... I'm clearly missing some definitions. What I had in mind is
to define the acquire fence as a memory barrier that would prevent all
subsequent memory operations from being moved ahead of any preceding loads.

In any case, regardless of the details of the fence, my fundamental point
was that if no ordering were to be implied by control flow, one alternative
to reduce the synchronization overhead is to provide a finer granularity of
barriers, which could themselves appear inside control flow as necessary.

As others have pointed out in this thread, having control flow imply memory
ordering is a difficult proposition for a high level language, as it
interferes with compiler transformations that reorganize the control flow.
The same could be said for data flow. What I'm proposing is to avoid having
such implied memory orderings, and instead give the programmer the tools to
explicitly specify which memory orderings are required.

--
Raúl E. Silvera         IBM Toronto Lab   Team Lead, Toronto Portable
Optimizer (TPO)
Tel: 905-413-4188 T/L: 969-4188           Fax: 905-413-4854
D2/KC9/8200/MKM



                                                                           
             Ben Hutchings                                                 
             <ben at decadent.org                                             
             .uk>                                                       To 
             Sent by:                  C++ threads standardisation         
             cpp-threads-bounc         <cpp-threads at decadentplace.org.uk>  
             es at decadentplace.                                          cc 
             org.uk                                                        
                                                                   Subject 
                                       RE: [cpp-threads] Yet another       
             12/30/06 06:40 AM         visibility question                 
                                                                           
                                                                           
             Please respond to                                             
                C++ threads                                                
              standardisation                                              
             <cpp-threads at deca                                             
             dentplace.org.uk>                                             
                                                                           
                                                                           




On Thu, 2006-12-28 at 07:52 -0500, Raul Silvera wrote:
<snip>
> What I am proposing, then, is:
>
> // x y initially zero
>
> // threads 1 to N:
>
> assert( x == 0 );
>
> if( fetchadd_release( &y, 1 ) == N - 1 )
> {
>     acquire_fence(); // prevent subsequent stores to x from moving before
any previous loads
>     x = 1;
> }
>
> Note that a explicit fence is something easy for the compiler to handle.
<snip>

Associating an acquire barrier with an operation means that subsequent
operations can't be moved before it (but earlier operations can be moved
after it).  An acquire barrier on its own is meaningless and is
certainly not equivalent to a store-load barrier.

Ben.

--
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison
(See attached file: signature.asc)--
cpp-threads mailing list
cpp-threads at decadentplace.org.uk
http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/octet-stream
Size: 196 bytes
Desc: not available
Url : http://www.decadentplace.org.uk/pipermail/cpp-threads/attachments/20061230/87d5c569/signature.obj