wolfpld
Fibers and mutexes
Hi, first of all many thanks for creating such a marvelous product.
I am trying to use Tracy in a system that has fibers and fiber mutexes. I notice that fibers show up in the capture - but not mutexes. If I disable fibers and use threads, then mutexes show up.
Is there an assumption that mutexes are thread based?
Yes, it's running for several loops, bun then stops with the "zone ended twice" message:
I got similar issue initially but that seems to be caused by incorrect or missing Fiber Enter instrumentation.
p.s. although in your case it may be mismatched Zone start/end?
In our code we have fiber mutexes, that work just like thread mutexes. So I can switch the code between fiber version and thread version. The instrumentation for mutex is unchanged and works fine in the thread version - so the issue might be that the Tracy frontend (server) is not associating a mutex lock with the active fiber.
Thank you very much, for the reply. I'm pretty sure, I do something with entering and leaving the coroutines wrong, but I don't know how to do it right. The best results I do get with the following code in my thread function:
auto JobSystemWorker::workerFunction() -> void
{
m_running = true;
while (m_running)
{
auto job = std::move(getJob());
if (job)
{
TracyFiberEnter(m_workerName);
(*job)();
TracyFiberLeave;
}
}
}
With "best results" I just mean, that the zones look correct in the server. But it still stops after some loops. In the thread function I just try to grab a suspended coroutine and resume it. It can happen, that the same coroutine is suspended and resumed multiple times, because the coroutine can have multiple lines with "co_await". It can also happen, that a coroutine is resumed by a different thread, than the one which has suspended it. If I run my application just with one thread, everything works fine.
FWIW, on Slides 61-62 below I have an alternative way to instrument mutex locks that works without any special Tracy knowledge or decoration: https://github.com/CppCon/CppCon2023/blob/main/Presentations/Tracy_Profiler_2024.pdf
It won't give you the neat visualization of lock/unlock flow, but it will show you contention, which in my experience is what is most relevant when instrumenting locks for performance profiling.
FWIW, on Slides 61-62 below I have an alternative way to instrument mutex locks that works without any special Tracy knowledge or decoration: https://github.com/CppCon/CppCon2023/blob/main/Presentations/Tracy_Profiler_2024.pdf
It won't give you the neat visualization of lock/unlock flow, but it will show you contention, which in my experience is what is most relevant when instrumenting locks for performance profiling.
Thank you
FWIW, on Slides 61-62 below I have an alternative way to instrument mutex locks that works without any special Tracy knowledge or decoration: https://github.com/CppCon/CppCon2023/blob/main/Presentations/Tracy_Profiler_2024.pdf
It won't give you the neat visualization of lock/unlock flow, but it will show you contention, which in my experience is what is most relevant when instrumenting locks for performance profiling.
Hi @slomp
I tried out your idea of faking locks as mempools. as you say it shows contention but sadly it won't show who holds the lock and who is waiting - which is something one would like to see.