17:09 <josch> hi, through https://sourceware.org/systemtap/wiki I got to this gist https://gist.github.com/myaut/ab4dd51ff811bd367328 what puzzles me is: because of the variable "lines" this probe will not be executed in parallel. If that variable wouldn't exist, could that probe be called in parallel with itself and thus could the output become gibberish again? Thanks!

17:27 <fche> hi

17:29 <fche> I think your intuition is about right

17:30 <fche> the global variable is indeed locked by stap, so if multiple processes named alloc-bench or threads of such a process were to do write syscalls at the same time, the presence of the stap probe will to some extent serialize them

17:31 <fche> but the stap probe runs very briefly, so the output of the userspace program may not be appreciably modified (considering that write(2) is supposed to be atomic anyway, to userspace)

17:32 <fche> (note also that if alloc-bench happens to be multithreaded, then the lines[pid()] style of indexing can internally mess up the systemtap side of the state, by multiple threads reusing the same slots

17:37 <josch> fche: thanks, my ultimate question is: if I do a print in one probe, could its writing of output to stdout be interrupted by another probe? Or can I rely on the write happening atomically?

17:37 <fche> ok, that's a different issue: what sort of serialization does stap itself promise for its output

17:38 <josch> right

17:38 <fche> just trying to look up or guess from memory

17:39 <fche> I believe output from a single probe handler is accumulated into a temporary buffer, then flushed in its entirety at probe handler conclusion

17:39 <fche> so multiple handlers running concurrently shouldn't have interleaved output appearing at stap's stdout

17:40 <josch> right, that's what i'm seeing in my tests

17:40 <josch> it's just hard to create a situation with interleave because just by chance stuff might not interleave ;)

17:41 <fche> ie. to confirm stap's implementation? yeah.