[fpc-other] Re: [fpc-devel] volatile variables

[Vinzent Höfler]

On Thu, 30 Jun 2011 10:38:18 +0200, Michael Schnell <mschnell at lumino.de>
wrote:

> But e.g. if you use a TThreadList instance "myList" with multiple  
> threads it can't be the way to go to include any occurrence of  
> myList.xxx by a critical section just to make sure that the cache  
> synchronization has happened and the instance variable itself in fact is  
> valid.

You're opening a can of worms here. :)

I think I see what you mean. In the old days, atomic read accesses were
at least known to be consistent, now even those aren't anymore. So, if
some (getter) subroutine does read some instance variable (let's say
myList.Count) without synchronising memory, it could see a different
values on different cores, AFAICS.

BTW, I found this paper quite useful in understanding the implications:

<http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf>

To sum it up, cache-coherence between the cores should be maintained by
the hardware, if one core is writing a value to it's cache, it is
responsible to inform the other cores about that their appropriate cache-
line is not up-to-date anymore.

So, the only problem the programmer has to take care of in multi-threaded
code is out-of-order execution of reads and writes. So it's not as bad as
it first seems, but it's still not easy to understand.

> Moreover I don't think it can be the way to go to enforce the  
> application programmer to plan his software in a way that somehow else  
> he needs to make sure that such an instance variable arrives in the  
> appropriate CPU's cache.

You're totally right here.

Still it is the responsibility of the application programmer that it
arrives in the correct /order/, if such an order is required.


Vinzent.