Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[TSan] Yet another idea about whitelisting data races #5310

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
lewurm merged 2 commits into from
Aug 10, 2017
Merged

[TSan] Yet another idea about whitelisting data races #5310

lewurm merged 2 commits into from
Aug 10, 2017

Conversation

@cherusker
Copy link
Contributor

@cherusker cherusker commented Aug 4, 2017 •
edited
Loading

I would like to propose another idea about how to deal with the instrumentation of data races. Inspired by atomic.h and the G_UNLIKELY macro, a (maybe the) solution might be to use inline functions that wrap around increments, additions, ...

The Main Problem:

  • Any kind of locking and synchronisation (like using the functions of atomic.h) is no option in performance critical situations like mempool.c.
  • TSan instrumentation can only be blocked on a function level; TSan can be told to ignore whole functions, however, it can not be told to ignore single instructions.
  • Big functions might contain "harmless" and harmful data races. By "harmless" I mean things like counters that are only used for debugging / reporting.
  • There are a lot of data races (> 30) that are simple reporting / debugging counters (e.g. the whole of mono_stats in class-internals.h).
  • Once a function is blacklisted, any alteration that produces a harmful data race in combination with that blacklisted function will not be detected. In fact, that is my main concern when blacklisting whole functions!

The Idea:

Using inline functions that follow the exact same interface like the functions in atomic.h.

  • Known data races can be documented in the code, exactly where they occur (no documentation is needed as it is extremely readable / transparent).
  • Due to inlining, the original machine instructions are not altered if TSan is not activated. Thus, there is no performance impact.
  • RacingIncrement () can be quickly changed to InterlockedIncrement (), should the need arise.

To demonstrate the idea, I used mono_stats in class.c as a specimen. I also tested proper function inlining on Fedora 26 with gcc 7.1.1 and clang 4.0.0 (both with -O2) and all results were as expected: The code was exactly the same - with RacingIncrementSize (&mono_stats.foo) and with ++mono_stats.foo.

I really hope that this idea gets accepted by the community since I would love to finally have the possibility of blacklisting single racy instructions. Detecting actual (harmuful) data races would be a lot more precise and reliable. If accepted, I would of course expand these function family (we will need things like RacingExchange (), RacingAdd (), RacingSub () and more) to tackle all races that are connected to debugging / reporting.

As we talked about this topic before, I would kindly ask at least @luhenry, @vargaz, @alexrp and @lambdageek about thoughts and opinions.

@dnfclas
Copy link

dnfclas commented Aug 4, 2017

@cherusker,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

alexrp
alexrp reviewed Aug 4, 2017
View reviewed changes
mono/utils/racing.h Outdated
Copy link
Contributor

@alexrp alexrp Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These functions should also be marked MONO_ALWAYS_INLINE.

alexrp
alexrp reviewed Aug 4, 2017
View reviewed changes
mono/utils/racing.h Outdated
Copy link
Contributor

@alexrp alexrp Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

explicitly

Copy link
Contributor Author

@cherusker cherusker Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!

@alexrp
Copy link
Contributor

alexrp commented Aug 4, 2017

I like this idea.

@cherusker cherusker changed the title [TSan] Yet another idea of whitelisting data races [TSan] Yet another idea about whitelisting data races Aug 4, 2017
alexrp
alexrp reviewed Aug 4, 2017
View reviewed changes
mono/utils/racing.h Outdated
Copy link
Contributor

@alexrp alexrp Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to add this file to mono/utils/Makefile.am and msvc/libmonoutils.vcxproj, msvc/libmonoutils.vcxproj.filters.

@cherusker cherusker force-pushed the cherusker-2017-08-04-racing-h branch from 388a26f to 7d30a0c Compare August 4, 2017 13:58
lambdageek
lambdageek reviewed Aug 4, 2017
View reviewed changes
mono/metadata/class-internals.h Outdated
Copy link
Member

@lambdageek lambdageek Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason to prefer glib types to standard C types in internal headers?

Copy link
Contributor Author

@cherusker cherusker Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just working with the code since June and most things I do are based on observation. Personally, I do not not have any preferences (yet). However, I understand that the glib types are preferred wherever possible. (I might be wrong there!)

My thought was that atomic.h uses gint* so it might be nice to use all g* types in racing.h to keep some kind of consistency. And, since racing.h works with gsize AND mono_stats has this guint64 value anyways, I thought that (again talking about consistency) it would be nice to have those affected fields defined as gsize in mono_stats as well.

@cherusker
Introduce racing.h
a72b665 
- introduce the `RacingIncrement* ()` functions
- test the `RacingIncrement* ()` functions with races of `mono_stats` in class.c
- add racing.h to Makefile.am, libmonoutils.vcxproj and msvc/libmonoutils.vcxproj.filters
@cherusker cherusker force-pushed the cherusker-2017-08-04-racing-h branch from 7d30a0c to a72b665 Compare August 4, 2017 15:01
@vargaz
Copy link
Contributor

vargaz commented Aug 4, 2017

Can we call this something other than racing ? Like Unlocked or something ?

@cherusker
Copy link
Contributor Author

cherusker commented Aug 4, 2017 •
edited
Loading

@vargaz Yeah sure, I like that idea; I'll change it to UnlockedIncrement () and unlocked.h etc!

@cherusker
[fixup!] Rename "racing" to "unlocked"
0712be3 
- rename racing.h to unlocked.h
- update new file name in Makefile.am and *.vcxproj* files
- rename the functions from Racing* to Unlocked*
- update the macro logic
@lewurm lewurm requested a review from luhenry August 7, 2017 16:33
@cherusker cherusker mentioned this pull request Aug 8, 2017
Closed
@lewurm lewurm merged commit bc84302 into mono:master Aug 10, 2017
@cherusker cherusker deleted the cherusker-2017-08-04-racing-h branch August 10, 2017 14:17
This was referenced Aug 15, 2017
Merged
Merged
monojenkins pushed a commit that referenced this pull request Aug 23, 2017
@cherusker @monojenkins
[TSan] Unlocking MonoStats, GCStats and JITGCStats (#5381)
787faec 
[TSan] Unlocking MonoStats, GCStats and JITGCStats

As the `Unlocked* ()` functions have been approved in #5310, I used them to blacklist some of the most obvious counting variables whose data races should be ignored: `MonoStats`, `GCStats` and `JITGCStats` (more to follow if approved).

Please find details about all changes within the commit messages.
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@cherusker @lewurm
[TSan] Yet another idea about whitelisting data races (mono/mono#5310)
16f806e 
* Introduce racing.h
- introduce the `RacingIncrement* ()` functions
- test the `RacingIncrement* ()` functions with races of `mono_stats` in class.c
- add racing.h to Makefile.am, libmonoutils.vcxproj and msvc/libmonoutils.vcxproj.filters

* [fixup!] Rename "racing" to "unlocked"
- rename racing.h to unlocked.h
- update new file name in Makefile.am and *.vcxproj* files
- rename the functions from Racing* to Unlocked*
- update the macro logic


Commit migrated from mono/mono@bc84302
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@cherusker @monojenkins
[TSan] Unlocking MonoStats, GCStats and JITGCStats (mono/mono#5381)
fe67d82 
[TSan] Unlocking MonoStats, GCStats and JITGCStats

As the `Unlocked* ()` functions have been approved in mono/mono#5310, I used them to blacklist some of the most obvious counting variables whose data races should be ignored: `MonoStats`, `GCStats` and `JITGCStats` (more to follow if approved).

Please find details about all changes within the commit messages.


Commit migrated from mono/mono@787faec
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

4 more reviewers

@alexrp alexrp alexrp left review comments

@lambdageek lambdageek lambdageek left review comments

@lewurm lewurm lewurm approved these changes

@luhenry luhenry luhenry approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

7 participants

@cherusker @dnfclas @alexrp @vargaz @lewurm @lambdageek @luhenry