Open nukep opened 1 day ago
Filed as internal issue #USD-10295
To clarify the doc you linked, it's not safe to modify the SAME stage from a child thread -- see https://openusd.org/release/api/_usd__page__multi_threading.html
Although it is not possible for multiple threads to simultaneously write "to the same stage", it is safe for different threads to write simultaneously to different stages.
@asluk In this particular case, only one thread is writing to the layer and nothing else. Because it's not "multiple threads", I believe this is adequate for thread-safety, unless there's some other nuance I'm missing.
I interpreted this document as saying "reading a layer from one thread and writing a layer from another is thread-safe". Is this true?
That is an incorrect interpretation. Just as the stl threading model, even if only a single thread is modifying a (e.g.) std::vector
, no other thread can even be reading from that vector concurrently. That's what the "multiple readers or single writer" is meant to convey - we're definitely interested in improving the language if that will help.
In usdview, the main thread may be doing imaging or GUI updating, which in turn will interrogate the stage, thus reading from the layer-being-mutated.
Thanks for clarifying @spiffmon, that makes sense. I must have interpreted the "multiple readers or single writer" claim as a logical or (multiple_readers || single_writer
) instead of a mutually exclusive or. :laughing:
As far as languages goes, I'd maybe suggest describing the restrictive relationship of concurrent read/writes, so something like "You cannot write to a stage or layer while another thread is reading the same stage or layer". And "Multiple threads can read from the same stage or layer as long as no other thread is writing to it".
To clarify why I filed this issue in the first place: My use case is that I'm interested in authoring the stage asynchronously when a result is "done", started by outside events not triggered by the user.
In usdview I think the UI thread is the rendering thread, so maybe I could put an event in the Qt event loop or something. I suspect there isn't a client-agnostic way of achieving this (for non-Qt DCCs), but if there is, that'd be of interest to me!
There was a nice presentation at DigiPro this year where Animal Logic tackled the same problem in their Filament application. I am not suggesting that you undertake a similar project in usdview, but I thought their article is a helpful read about the issues involved in keeping a UI responsive under the single-writer/multi-reader paradigm. https://dl.acm.org/doi/abs/10.1145/3665320.3670992
@meshula Interesting! Thanks, I'll take a look
Description of Issue
If a prim is created and removed on a layer from another thread in a very short amount of time, this can cause a segmentation fault in usdview. I've observed this happening for longer durations as well, but it's harder to reproduce.
I believe this is a bug because this page suggests that writes to a stage are thread-safe: https://openusd.org/dev/api/_usd__page__multi_threading.html
Depending on chance, I sometimes see the following message logged in the terminal:
Steps to Reproduce
System Information (OS, Hardware)
Rocky Linux 9.4 (Blue Onyx)
Package Versions
OpenUSD v24.08: https://github.com/PixarAnimationStudios/OpenUSD/tree/v24.08
Build Flags
Cmake flags: