Volatile and Windows Threading?

[waynebe]

How important is it to mark your cross process variables and cross thread variable as Volatile with Hyper-Threading? For example delcaring them:

int volatile a;

instead of:

int a;

-Wayne

[davids]

I would not recommend using volatile for ensuring memory visiblity among threads or processes. I would advise using critical sections and mutexes. Unfortunately, there doesn't seem to be a formal memory visibility specification, so there's really no way to know what's right.

Volatile does happen to work. But whether it will continue to work on future processors is an open question. It's hard to imagine that it will work on Itanium processors unless the compiler starts emitting fences on volatile variable accesses.

[Intel_C_Intel]

> How important is it to mark your cross process
> variables and cross thread variable as Volatile with
> Hyper-Threading?

For C, they are only important to the compiler. They stop compiler orderings. C volatile?s won?t do anything when it comes to memory visibility. I think Itanium specific C/C++ compilers will ?auto-fence? volatile access, maybe as an option.


> How important is it to mark your cross process

If you don't want the compiler to use the vars in optimizations, then it?s important.


int a = 0;

If your going to manipulate a, you would use one of the following methods...


/* Load */

int b = a;
asm__ { lfence };


or


/* Load */

int b = (int)InterlockedCompareExchange( (LPLONG)&a, 0, 0 );



/* Store */

a = b + 1;
asm__ { sfence };


or


/* Store */

InterlockedCompareExchange( (LPLONG)&a, (LONG)(b + 1), (LONG)b );



Those will all work.

;)

[Intel_C_Intel]

> How important is it to mark your cross process
> variables and cross thread variable as Volatile with
> Hyper-Threading?

"Hyper" aside for a moment, C/C++ volatiles are totally brain-damaged arhaic creatures that shall better be deprecated sooner than later. Don't use C/C++ volatiles unless you really "have to"... and I won't go into "have to", sorry (but "see" the link in the sig). Well,

http://google.com/groups?selm=QJZo9.17%24X93.717939%40news.cpqcorp.net

regards,
alexander.

--
http://google.com/groups?threadm=3DD4E119.CB51D2D6%40web.de

[waynebe]

Ok just to be clear, I am using:

LONG violate a;

and doing InterlockIncrement, etc on the LONG. So if I am doing that I don't need to have a violate right?

-Wayne

[bronx]

> LONG violate a;
>
> and doing InterlockIncrement, etc on the LONG. So if

the InterlockedIncrement routine was compiled without access to your source code so indeed your volatile qualifiers will have no effect on its behavior, for the "etc" things just apply the same reasoning


> I am doing that I don't need to have a violate
> right?

difficult to tell for sure without access to your source code, but don't be so violent with your variables : it can backfire later on ;-)

[Intel_C_Intel]

> Ok just to be clear, I am using:
>
> LONG violate a;
>
> and doing InterlockIncrement, etc on the LONG. So if
> I am doing that I don't need to have a violate
> right?

Right.

If you always use the Interlocked API's to access shared variables your safe.