[fpc-devel] volatile variables
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