parallelism: how can I ensure data is seen by another thread or consumer?

do {
synchronize_with_other_thread();
int* buffer_nonvolatile = (int*) buffer; // buffer being qualified
volatile
for (int i=0;i<8;++i) {
sum += buffer_nonvolatile[i];
}
} while (sum < THRESHOLD);

do {
synchronize_with_other_thread();
int* buffer_nonvolatile = (int*) buffer; // buffer being qualified
volatile
for (int i=0;i<8;++i) {
sum += buffer_nonvolatile[i];
}
} while (sum < THRESHOLD);

>

>do {
synchronize_with_other_thread();
int* buffer_nonvolatile = (int*) buffer; // buffer being qualified
volatile
for (int i=0;i<8;++i) {
sum += buffer_nonvolatile[i];
}
} while (sum < THRESHOLD);

To do that you need buffer to be a volatile pointer, not a pointer to a
volatile integer.
This way the compiler will assign buffer_nonvolatile to buffers value each
time through the loop, thus it *could* change value and a compiler won't
optimise it away right?

Wrong. A smart compiler will figure out to store the last value of the non
volatile pointer, and if its the same value this time, it will use the same
sum values instead of fetching them again. So you really need buffer to be a
volatile pointer to a volatile integer, which means your buffer_nonvolatile
pointer does have to be pointing to volatile data after all.... in other
words your code is wrong and if it wasn't it would be pointless anyway. You
should just make buffer_nonvolatile volatile. But i guess this depends on
what your sync is doing.

>The*problem*I*see*here*is*that*only*the*content s*
of*buffer[]*are*volatile,*not*its*address.

You do know that:
volatile int *foo;
declares a pointer to a volatile integer, not a volatile pointer.
To do a volatile pointer to a normal integer you would do: int * volatile
foo;
and a volatile pointer to a volatile integer you do: volatile int * volatile
foo;

Sorry if my explanation was not clear enough, but I think you did
not contradict, but basically confirm what I assumed (but was not
really sure about): There is no other means of ensuring current data
from the buffer is read but declaring and using the data
volatile. It is not possible to temporarily have non-volatile access
to otherwise volatile data.

Perhaps I did not make it clear enough that my idea was to get rid
of the volatile-ness in some compute intensive kernel. Assume, e.g.,
buffer[] contains data for an image, and a complex filter--having
enough potential for optimization by the compiler--should be applied
to it. If you write parallel applications, preventing aggressive
compiler optimizations by having everything volatile is most
probably not what you want.

>Perhaps I did not make it clear enough that my idea was to get rid
of the volatile-ness in some compute intensive kernel. Assume, e.g.,
buffer[] contains data for an image, and a complex filter--having
enough potential for optimization by the compiler--should be applied
to it. If you write parallel applications, preventing aggressive
compiler optimizations by having everything volatile is most
probably not what you want.

Yes, and it is very unlikely that you have to resort to that sort of
thing. The trouble is that you won't find out here. Standard C has
nothing to say about concurrency and what it has to say about volatile
is not enough for you know what is and is not safe.
The system you are programming for must provide thread primitives and
its documentation (or a Usenet group about it) is the only place where
you will find out what is and is not guaranteed. There will, most
likely, be some simply synchronisation primitive that will allow the
producer to put a pointer to a new frame into some queue where it can
be consumed by the filter without any interference.

If there is not, then you need to build one. Ask, say, in
comp.programming.threads about building a semaphore from whatever
atomic memory operations your system provides.

Perhaps I can bring all my quite long emails down to the following question:

According to the language standard (not from a practical view that
exploits the weaknesses of compilation): Is it necessary or not to
have each and every object that is changed by one and read by
another thread after proper synchronization to be qualified volatile
if one wants to ensure the second one also gets the new contents?

[...] Whatever extension you are using that provides the concurrency must do
so with some basic set of primitives. These are what you need to use. [...]

>
The C standard say nothing about concurrency

If standard C ever embraces concurrency it will have to provide some
sort of guarantees about the memory model but I'd bet the house that it
won't do that via tightening the meaning of volatile -- it will most
likely borrow the work done in the C++ committee.