Exclude multithreaded main-main races by threadflag
This is a bit silly but the threadflag analysis may_race did not exclude main-main races even though it has all the information to do so.
It almost never makes a difference because threadflag answers the MustBeUniqueThread query based on its flag still, and the threadid analysis uses that information in its may_race.
The more notable thing is the unexpected cram test (change). Usually accesses while single-threaded aren't even added to allglobs, but apparently the thread ID variable write in pthread_create is added although as if single-threaded. This is odd for two reasons:
- As single-threaded it shouldn't even be in
allglobs. - It's actually ambiguous whether it should be written before or after the thread is created. Maybe it should be done after, thus in multi-threaded mode altogether to over-approximate the possibility.
This was always in the cram test but went unnoticed until I played around with this.
EDIT: The original implementatin in 03b737ecda48cc107082af70e4f6ec949c90a993 used to exclude these directly by requiring at least one access to be non-main. However, it seems like it might have not excluded races between single-threaded and multi-threaded–non-main, at least directly.
Any reason this is still a draft? We should be able to merge to reduce the number of in-flight PRs, right?
It's a draft because I think this simple thing also makes some cases less precise by not incorporating some query. It's probably fixable but the bigger question might be if this improvement is useful enough to have.
The other interesting matter is regarding the pthread_create ID assignment. It doesn't need to be fixed here but might be worth treating separately even.
Usually accesses while single-threaded aren't even added to
allglobs, but apparently the thread ID variable write inpthread_createis added although as if single-threaded. This is odd for two reasons:
As single-threaded it shouldn't even be in
allglobs.It's actually ambiguous whether it should be written before or after the thread is created. Maybe it should be done after, thus in multi-threaded mode altogether to over-approximate the possibility.
In some random version of glibc I looked at, the thread ID argument is written before the thread actually starts executing.