[fpc-devel] volatile variables

Michael Schnell mschnell at lumino.de
Wed Jun 29 10:17:43 CEST 2011

On 06/28/2011 10:25 PM, Hans-Peter Diettrich wrote:
> Can you run your test again, assuring that only one thread can access 
> the list at the same time, but *without* the Interlocked updates?
This would be a very nice move of Andrew's !!!

If he uses a single TCriticalSection instance to protect all accesses to 
the variables (seemingly a set of pointer structures used to create a 
double linked list) this is bound to work correctly on any hardware with 
any count of cores under all circumstances.

Otherwise there is some bug.

And this bug needs to be located.

If it is in the user software, Andrew will be able to fix it.
If is is in the RTL/LCL we need to issue a patch request here.
If it is in the Linux infrastructure (libraries or OS) an appropriate 
patch request can be generated as well
If it is in the Windows infrastructure we are out of luck.
If it is in the hardware, same needs to go  to the trash bin

BTW. The fact that the current code with interlocked instructions works 
on a higher core-count engine than the code without, does not mean that 
it in fact is correct or even better, as this drastically changes the 
timing and might just by chance prevent concurrency from occurring. In 
fact, IMHO, interlocked instructions are not appropriate here, anyway, 
as same are constructed to ensure single-Word variable atomic behavior 
(necessary e.g. to construct a MUTEX or Semaphore). But here, 
multi-variable atomicity is necessary and same is only possible using a 
critical section of some kind (and within same - by Posix definition -  
atomicity and concurrency-protection is granted anyway, thus interlocked 
instructions do nothing but slow down the code <and with that change the 
thread-related behavior of the code> ).


More information about the fpc-devel mailing list