Open johnkdoe opened 7 years ago
What unit tests? How can I repro? The move to stdatomic SHOULD have solved this and for thread sanitizer to still elicit warnings makes me want to double check that we are properly accessing the variable everywhere.
I did some research and volatile
is not necessary with the std::atomic
variables, of which __sharedLoggerLevel is one. We should probably skip this change, and just remove the volatile
keyword. I'm happy to do that, but I don't know how to repro this sanitizer error you're seeing; @johnkdoe can you try that change and see if stops?
UPDATE: std::atomic is for C++, which is not what we are using here. We are using
for Twitter, was getting this just running the "Bluebird Enterprise" scheme, performing unit tests with thread sanitizer turned on. can try to re-test with __sharedLoggerLevel established as a non-volatile …
deleted last 2 comments with stack-traces of thread-sanitizer … and also got the latest proper SHA1 for the develop branch …
I guess the thread sanitizer is technically correct, __sharedLoggerLevel is, by design, a race between writes & reads. It doesn't matter though, as long as it is updated atomically. I'm surprised the thread sanitizer isn't more cognizant or accepting of usage patterns like this. I suppose the only thing we can do is disable it the check, as you've proposed in this request.
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
during unit-testing with the thread-sanitizer on, setLoggerLevel: was flagged unnecessarily as a potential data-race.
__sharedLoggerLevel is already marked volatile, and the location of the data race indicated was a debug logging message .