Has anyone ever seen an instance where TBB Atomics (specifically, unsigned 64 bit integers) failed on fetch_and_add?
I am having the following situation:
- two or more threads concurrently fetch_and_add(1)
- for the first two threads that fetch_and_add, the values returned from those two operations are identical, even
though the addition operand is non-zero. All remaining threads that fetch_and_add return sequential values, as one would expect.
I'm not one to question the capabilities of the Intel Development staff, but has anyone ever seen an instance where the operations were not truly atomic? I am running on 2-socket, Quad Core Intel Xeon 64 bit processors.
FYI: I'm running SUSE Enterprise Linux 11, and I'm using the Intel Compiler, version 11.1.
Just afew clarifying questions: in addition to 64 bit processors, do you also use the 64 bit OS, and do you compile the code for 64 bits as well? Also which exactly build of the Intel Compiler 11.1 (i.e. what are the third group of digits in the compiler version? And which version of TBB?
It turns out that once every 70-100 million instances, a very awkward race condition was causing the above problem. So it would seem that the atomics library is indeed doing its job.
I doubt you're still interested, but I'm using 64 bit OS, compiled for 64 bit, and the ICC build number is 056.
If you can, open a dissassembly window andstep into/through the fetch and add.
Record the address at which the variable lies (checking boundary problems). Report address here. Boundary problems being not aligned on 64-bit address.
Next observe what code is being executed. If you can capture a screenshot or text therefromand post it here that would be nice.