[fpc-devel] volatile variables

[Michael Schnell]

On 06/30/2011 11:31 AM, Hans-Peter Diettrich wrote:
>
>
> Consider the shareable bi-linked list, where insertion requires code 
> like this:
>   list.Lock; //prevent concurrent access
>   ... //determine affected list elements
>   new.prev := prev; //prev must be guaranteed to be valid
>   new.next := next;
>   prev.next := new;
>   next.prev := new;
>   list.Unlock;
I really would like to see a test case proving my assumption wrong that 
this in fact just woks

We found that
  - my original "volatile" question is invalid, as the function calls 
done with list.lock and list.unlock are a "volatile barrier" preventing 
the compiler from caching some value inappropriately in a register, 
simply because they are function calls.
  - the MUTEX operations done with list.lock and list.unlock (at least 
on PCs in Linux and Windows) use library calls that includes memory 
barriers
  - if the potential cache incoherency would not be handled by Hardware 
/ OS / Libraries on behalf of user land programs, I feel that this would 
so disastrous and ubiquitous that it result in so many programs not 
working on SMP systems that it would be a really well known issue.

-Michael