News for hackers. Stuff that matters.

A comment on 0+0 > 0: C++ thread-local storage performance. Parent comment

Re:0+0 > 0: C++ thread-local storage performance by yosefk on Monday February 17, 2025 @02:11PM (#43082278)
For a tracing profiler, you want to know which thread a function call or return was made by. LTTng has kernel modules which it can use to trace context switches, and then a per-CPU trace buffer is fine, provided that you get cheap atomic writes which rseq can be used for.

Funtrace on the other hand does support ftrace for tracing context switches (https://yosefk.com/blog/profiling-in-production-with-functio...), but it doesn't require ftrace for tracing function calls made by your threads (the problem with ftrace as well LTTng's kernel modules being, of course, permissions; which shouldn't be a problem in any reasonable situation by my standard of "reasonable", but many find themselves in unreasonable situations permissions-wise, sadly.) So I don't think funtrace can use rseq, though I might be missing something.

[ Parent | on HN ]
Re:0+0 > 0: C++ thread-local storage performance by HALtheWise on Tuesday February 18, 2025 @12:56AM (#43086488)
Presumably you could store the TID in every event, or otherwise check whether the TID has changed since the last time it was logged and push a (timestamp, TID) pair if so. Reading TID should be cheap.
[ Parent | on HN ]
Re:0+0 > 0: C++ thread-local storage performance by yosefk on Tuesday February 18, 2025 @01:12AM (#43086578)
In what sense should reading the TID be cheap? You would need either a syscall (not cheap) or thread-local storage (the subject of TFA.) Avoiding the use of TLS by reading the TID can't really work
[ Parent | on HN ]
Re:0+0 > 0: C++ thread-local storage performance by HALtheWise on Tuesday February 18, 2025 @02:17AM (#43086884)
It looks like the TID is stored directly in the pthread struct pointed to by %fs itself, at a fixed offset which you can somewhat-hackily compile into your code. [0]

In the process of investigating this, I also realized that there's a ton of other unique-per-thread pointers accessible from that structure, most notably including the value of %fs itself (which is unfortunately unobservable afaict), the address of the TCB or TLS structures, the stack guard value, etc. Since the goal is just to have a quickly-readable unique-per-thread value, any of those should work.

Windows looks similar, but I haven't investigated as deeply.

[0] https://github.com/andikleen/glibc/blob/b0399147730d478ae451...

[1] https://github.com/andikleen/glibc/blob/b0399147730d478ae451...

[ Parent | on HN ]