Thread safety?

[focustense]

The wiki doesn't have much to say about this, and I saw one current issue referring to planned MT support in a specific area, so I'm a little hazy on what is or is not thread-safe at present.

Can I concurrently iterate/inspect a bunch of records from a bunch of different mods and expect everything to just work?

What about writes - can I edit several records at once? Deep-copy several records at once?

I might as well try to use up a few of these 16 logical cores and try to bring task completion times down from 2 minutes to 15 seconds. But there's probably some sequential file I/O involved here, and file I/O can be tricky. On the other hand, file I/O involves a whole lot of waiting around, so it's worth trying to parallelize whatever can be parallelized, but I wouldn't expect it to just work unless you've specifically considered MT/async-IO as a use case.

Something about the phrase "binary overlay" whispers "single-threaded" to me, but I figure it doesn't hurt to ask.

[Noggog]

Hey! Good question. I'll see if I can write a wiki entry about general thread safety.

The short answer is that any read functionality should be thread safe. Just be careful to not put Group accesses in any loops or anything, while threadsafe, are very slow if done repeatedly with no caching. (https://github.com/Mutagen-Modding/Mutagen/wiki/Binary-Overlay#best-practices)

Writing has no thread safety built in, but that doesn't mean you need to lock, depending on the work being done. For example, if you have a thread per group, that is safe, as no two threads will be modifying the same group at once. If you have two threads adding to Npcs, though, then you'll want to lock the npc group object.

Similarly, it's safe to modify contents of records on multiple threads if you are changing different things. If two threads are modifying the items on a container, though, that'd be a case where you'd want to lock the container's item list object, etc.