Stewart Smith wrote:
On Fri, Jul 24, 2009 at 07:47:30PM -0400, Jay Pipes wrote:
OK, so, I've tracked down the issue I was having with the replication
branch to a difference in behaviour in atomic<> variables on CentOS
(osindriz03) vs. other machines...hoping someone has an answer.
Here is the code which is behaving differently depending on the platform:
log_offset is declared as drizzled::atomic<off_t>.
log_offset= 0;
uint64_t length= 42;
off_t cur_offset;
cur_offset= log_offset.fetch_and_add((sizeof(uint64_t) + length));
On ALL other platforms other than CentOS 5, the above code sets
log_offset AND cur_offset equal to 50.
On CentOS, it sets log_offset to 50 and cur_offset to 0.
What does this mean? It means that the assignment to cur_offset is
happening *before* the call to drizzled::atomic<off_t>::fetch_and_add().
Without resorting back to mutexes, I am uncertain how to solve this
particular timing/atomics problem. I'm hoping someone out there has
more experience dealing with this.
Is this repeatable just in a single thread?
small test program?
i think it'd be useful to look at the disassembled binary produced (and,
well, diff them :)
I have a few theories in my head, but will have to look more closely
(when not really hanging out for lunch and lebanese coffee on a saturday :)
but if you can get me binaries from both machines, preferably even ssh
access, and point me at the right branch, will have a go.
Just an FYI, it turned out to be a bug in Intel TBB. Monty is updating
the atomics.h to only use the GCC atomics implementation, even when TBB
is present.
I'll put together a bug and test case for TBB and submit it to Intel.
Cheers,
Jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
