Page MenuHome

RNA: Protect accessors that write data with a global mutex.
ClosedPublic

Authored by Bastien Montagne (mont29) on Jul 28 2021, 5:50 PM.

Details

Summary

Ideally accessors should never create or modify data, but there are some
cases where this bad behavior is currently unavoidable.

This is the case of the Pointer accessor when the actual IDProperty has
not yet been created.

There is now a global mutex (LOCK_RNA) to make such cases thread-safe.

NOTE: this fixes a memory leak in liboverride diffing process when several different overrides use a same linked reference ID.

Diff Detail

Repository
rB Blender
Branch
rna-accessor-thread-safety (branched from master)
Build Status
Buildable 16095
Build 16095: arc lint + arc unit

Event Timeline

Bastien Montagne (mont29) requested review of this revision.Jul 28 2021, 5:50 PM
Bastien Montagne (mont29) created this revision.
Bastien Montagne (mont29) added inline comments.
source/blender/blenlib/BLI_threads.h
77

Not sure about the name, maybe LOCK_RNA_READ would be better? To enforce this should only be used in some exceptional accessor case?

Brecht Van Lommel (brecht) requested changes to this revision.Jul 28 2021, 6:09 PM
Brecht Van Lommel (brecht) added inline comments.
source/blender/blenlib/BLI_threads.h
77

This global list of locks should be avoided, just add a local static ThreadMutex lock = BLI_MUTEX_INITIALIZER; in the function.

source/blender/makesrna/intern/rna_access.c
3703

Can we lock only when the pointer does not exist yet, inside RNA_property_pointer_add?

We might access this many times, but only rarely do we actually need to allocate something.

This revision now requires changes to proceed.Jul 28 2021, 6:09 PM

Updated from review.

Bastien Montagne (mont29) marked an inline comment as done.Aug 3 2021, 12:26 PM
Bastien Montagne (mont29) added inline comments.
source/blender/makesrna/intern/rna_access.c
3703

Not sure I understand that comment? RNA_pointer_add() also calls RNA_property_pointer_add, so adding the lock inside RNA_property_pointer_add would actually make it used more often?

Further more, we already checked at the beginning of that function (RNA_property_pointer_get) that this is not currently allocated (the idprop = rna_idproperty_check(&prop, ptr) in the first if) ?

So I think locking here is the best solution?

Also missing a comment about why we do not check again for existence after locking here (since it's done by RNA_property_pointer_add itself), will add with update for the other remarks.

I missed that the check was already there, looks good then.

This revision is now accepted and ready to land.Aug 4 2021, 6:17 PM