question on semantics

[chris jefferson]

Chris Friesen wrote:

> I'm not sure who I should address this to...I hope this is correct.
>
> If I share memory between two processes, and protect access to the 
> memory using standard locking (fcntl(), for instance), do I need to 
> specify that the memory is volatile?  Or is the fact that I'm using 
> fcntl() enough to force the compiler to not optimise away memory 
> accesses?
>
> As an example, consider the following code, with <lock>/<unlock> 
> replaced with the appropriate fcntl() code:
>
>
> int *b;
>
> int test()
> {
>     b=<address of shared memory>;
>
>     while(1) {
>         <lock>
>         if (*b) {
>             break;
>         }
>         <unlock>
>     }
>     <unlock>
>
>     return *b;
> }
>
> Without the locks, the compiler is free to only load *b once (and in 
> fact gcc does so).  Is the addition of the locks sufficient to force 
> *b to be re-read each time, or do I need to declare it as
>
> volatile int *b;
>
Offically you have to declare volatile int *b. Although I can't be sure 
however, looking at this sample of code gcc will re-read the values 
anyway, as if fcntl are included in a seperate binary, gcc will probably 
not be able to tell that the value *b couldn't be changed by the call 
the fcntl, so will dump it to memory before the function call and read 
it back afterwards. While it's a little dodgy, in the past I've often 
made sure gcc re-reads memory locations by passing a pointer to them to 
a function compiled in a seperate unit. If gcc ever gets some kind of 
super-funky cross-unit binary optimisation, then this might get 
optimised away, but I wouldn't expect such a thing soon :)

Chris


> Thanks,
>
> Chris