Comment 8 for bug 954257

Well, the reason this lock was static is because TypedWritable is the base class of almost every object in Panda, and for low-memory environments it can be important to keep the size of this class as small as possible. The extra word in every object that a lock will require can add up after a while. Also, the list it protects is only rarely used, so there's very little cost in terms of parallelism for using a global lock here.

From the stack trace, it seems that the fundamental cause of the assertion is not that the static lock is protecting a non-static pvector (which is an uncommon design, but not fundamentally wrong), but simply a problem with statically-declared LightMutex objects in general. The problem is that when the application ends and all the static destructors are called, the relative order of the destructors between different modules is undefined; and in this case it appears to be destructing at least one TypedWritable object *after* _bam_writers_lock has already destructed.

I think a better solution is to redefine _bam_writers_lock as a "static LightMutex *_bam_writers_lock", and allocate it the first time it is used. Then it will never attempt to destruct. Some care will need to be taken to ensure there is no race condition when it is allocated, for instance following the example of AttribNodeRegistry::make_global_ptr().

David