d16
Subj : Re: Memory Barriers, Compiler Optimizations, etc.
To   : comp.programming.threads
From : SenderX
Date : Fri Feb 04 2005 10:08 pm

>> I use volatile for source code documentation only. That about how usefull 
>> it
>> really is wrt this kind of stuff.
>
> So if you want to write something like this:
>
>  int data;
>  bool dataIsReady;
>
>  ...
>
>  data = 22;           // set data to communicate to other threads
>  dataIsReady = true;  // let other threads know that they can read data
>
> How do you ensure that the compiler doesn't invert the order of those
> assignments?

You could use volatile and cross your fingers, or put it "all" in a mutex... 
But, we want a speedy lock-free solution, like your example shows. You could 
identify this code as a "critical-sequence" of operations and, IMHO, do it 
in assembly. I am starting to find that assembly language can be a lot more 
useful than C wrt lock-free programming in general; It eases my mind... lol. 
I have become more and more paranoid about this subject because the i686 
version of my AppCore library is done. All that I have left to do is finish 
the documentation. People may start to use it because of the high-peformance 
its provides, and I want there experience to be a good one. So, I'll quickly 
scribble down an ad-hoc lock-free solution for your question in C and i686:


/* C-style compile-time assertion for 32-bit cpu */
struct 32bit_compile_assert_int_must_be_a_word
{ int test[( sizeof( int ) == 4 ) ? 1 : 0]; };


/* MUST be two "adjacent" words!!! */
typedef struct __attribute__( (packed) ) cs_
{
    int data;
    int dataIsReady;

}   cs_t;


/* "safely" produces data. Safe is good! */
extern void i686_cs_produce_data( cs_t*, int );
..globl i686_cs_produce_data
i686_cs_produce_data:
    movl 4(%esp), %eax
    movl 8(%esp), %ecx
    movl %ecx, (%eax)
    ; sfence may be needed right here on future x86
    movl $1, 4(%eax)
ret


/* abstract this cpu specific code into common api. */
#define cs_produce_data i686_cs_produce_data /*  ;)  */




/* now, a thread-safe version of your example in C */
static cs_t my_data = { 0, 0 };


cs_produce_data( &my_data, 22 );


>>> How do you ensure that the compiler doesn't invert the order of those
> assignments?

Now the compiler doesn't even have a chance to reorder anything.

:)




> It seems reasonable to me, and it's consistent with another posting I just
> made.  In theory, you could get arbitrarily fine-grained with the
> information you pass to the compilers this way.

Yeah, I thought it could be a simple and straight forward method for passing 
all sorts of critical information about your custom functions directly to 
the compiler.




> Unfortunately, pragmas are
> defined to be inherently platform-specific, and my guess is that it'd be
> very difficult to get the C or C++ committees to standardize pragmas.

That's what I thought. However, I think the idea, at least, justifies a 
thoughtful discussion in the C/C++ committees.




> A
> similar idea is something like Microsoft's attributes, which, oddly 
> enough,
> might be easier push, because it's introducing something brand new rather
> than changing the semantics of something that currently exists.

Humm...

.

0