On Tue, 28 Jun 2011 15:54:35 +0200, Michael Schnell <mschn...@lumino.de>
wrote:
But if you do the same with
volatile static int x;
the code will stay and another thread can watch x growing in a time
sharing system.
No, it can't. "volatile" just ensures that accessing the variable results
in
actual memory accesses. That does not mean cache-coherence, so another core
may still see other (as in "older") values.
I believe that inserting some ptherad_mutex... calls will not force the
compiler to bother about some intermediate values of a non volatile
variable.
Well, then it's probably overly aggressive or buggy.
I believe that with FPC global variables are assumed to be volatile and
not optimized away or cashed in registers. But what about heap-variables
?
They are not volatile, I'd guess. And I don't see the need to assume they
are. You would always need proper synchronisation constructs here.
Thus true for global variables, not necessary true for static variables
as they can't be accessed by a function defined in another module (I
don't know whether the C compiler makes a difference)
It should not. It can't possibly assume that a call to pthread_...()
wouldn't
result in a recursive call back to the caller... ;)
Vinzent.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
