- User Since
- Dec 6 2012, 2:31 AM (319 w, 4 d)
Thu, Jan 10
Benchmark results with clang:
Tue, Jan 8
Mon, Jan 7
Sun, Jan 6
Fri, Jan 4
Thu, Jan 3
What are tagged pointers? When they are used? What is the actual value? How does synchronized handle them? Is there a man page or something with more info? It should be included in the comment for future generations.
Wed, Jan 2
I've benchmarked on 350140 with host gcc version 7.3.0 (Debian 7.3.0-5), running old/new binary alternated:
Sun, Dec 30
This needs some tests, at least to exercise interceptors code once.
Nice! Interesting nobody reported this false positive on user-space code.
Dec 22 2018
I would like to land this and fix @synchronized with tagged pointers in a follow-up since more discussion is required what we actually want it to do.
Dec 21 2018
Dec 20 2018
Dec 19 2018
Merged as 349609.
Merging this now.
Dec 18 2018
FTR, here is current code:
I added default synchronization and flag to opt-out.
I don't completely follow logic behind cur_thread/cur_thread_fast/cur_thread1 and how it does not introduce slowdown.
cur_thread_fast still includes an indirection, so it looks exactly the same as the first version.
cur_thread_fast does not check for NULL, so I would expect it to be used only in few carefully chosen functions. But it's used in most entry functions. Which makes me wonder: when cur_thread_fast cannot be used if it can be used in all these places?
It seems that you use cur_thread only to lazily initialize cur_thread1 in Initialize or ThreadStart. But then the question is: why don't we explicitly intialize cur_thread1 in these functions, and then just have a single cur_thread function as before with no 2 subtly different accessors?
Can't agree with this. Only fiber is visible to user. Of cause, it is the same as thread until user switches it.
Dec 12 2018
Dec 11 2018
Thinking of how we can eliminate the indirection in cur_thread...
Lingfeng, thanks for extensive feedback.
Dec 10 2018
FTR, Lingfeng did prototype change to qemu that uses these annotations:
Dec 3 2018
Some high-level comments:
- Do we want to synchronize fibers on switch? If fibers use TLS data, or cooperative scheduling (e.g. mutex unlock directly schedules the next critical section owner), or pass some data from prev fiber to next fiber, in all these cases not synchronizing fibers on switch will lead to false positives. As far as I remember in my old experiments I concluded that it's almost impossible to get rid of false positives it tasks/fibers are not synchronized on switch.
As per offline discussion: none of these tests test something that was used in user-space. So it does not make sense forking them for userspace/kernel.
Nov 30 2018
Nov 29 2018
Nov 27 2018
I think single threaded programs would also benefit from swapcontext support. At the very least it will give correct stacks. I think tsan shadow stack can also overflow on some fibers patterns (if a fiber has uneven number of function entries and exits).
I'd like to make sure that the work can be re-used to implement proper understanding of Darwin GCD queues.
It's unclear how this is supposed to be used. I would expect to see an interceptor for swapcontext that will make use of this, but there is none...
If these annotations are supposed to be user callable (are they? why?), we also need interface declarations in:
We also need tests (lots) that demonstrate how this can be used and that this works.
Nov 26 2018
Nov 23 2018
Nov 21 2018
Committed in r347383
Do you want me to merge this or you have commit access?
Nov 20 2018
Nov 19 2018
Nov 17 2018
Nov 15 2018
We need tests for these functions in compiler-rt/test/tsan/
Oct 31 2018
Oct 29 2018
Otherwise looks good to me.
Oct 27 2018
Oct 12 2018
Is it possible to make it just part of tsan without introducing a separate static library? That would be more scalable and easier to use.
Sep 18 2018
Looks good to me
Sep 17 2018
Aug 17 2018
Aug 13 2018
Jul 26 2018
Sure. Merged as 338023. Thanks.
Jul 25 2018
Jul 24 2018
Jul 20 2018
Submitted in 337531
Jul 16 2018
Jun 22 2018
Jun 14 2018
Jun 13 2018
Jun 12 2018
Jun 9 2018
And we did not even get to windows, mac, fuchsia and akaros.
Well on Linux you can check process infos on /proc/<proc>/status I believe but that might be overkill.
True ideally what I tried to say in the description is ideally the cpu load ought to be checked first but that s a lot of code :-)
I understand your points, but usually see the jobs are often bound to cpu0 while this cpu can be potentially pretty busy.
What's the gain? Performance improvement? What are the numbers for benchmarking?
Jun 7 2018
So your current version is actually the best one.
Thanks for bearing with me.