id summary reporter owner description type status priority milestone component version resolution keywords cc blockedby blocking notify_on_close platform project 3139 Thread-safe Atom deletion tic20@… Eric Pettersen "Tristan suggests using a shared pointer for Atom to avoid deleting the C++ Atom when a thread (e.g. structure validation during ISOLDE MD) is using it. Begin forwarded message: From: Tristan Croll Subject: Re: ISOLDE and ChimeraX plan for the future Date: May 4, 2020 at 3:24:17 PM PDT To: Tom Goddard Hi Tom, Coming back to your question on things from the ChimeraX end that I think could help ISOLDE. I can think of a few - some quite easy, some a little more complex. [... building side-chains stuff deleted ...] More difficult, but I think important for further performance improvements: making the core AtomStruct C++ objects safe to use in threads. Not fully thread-safe (a *lot* of work, and could easily reduce single-thread performance), but ensuring that things don't explode if an atom is deleted while a thread is running. I *think* this might be possible reasonably easily by wrapping the objects currently stored as raw pointers managed with new/delete in std::shared_ptr - a ""delete"" operation from the GUI would then just drop the shared pointer, but the object's destructor won't actually be called until the last reference to it goes out of scope. You could then give the class a Boolean ""deleted"" flag so anything using it knows to skip it. There may be other complications I haven't thought of, but if it can be done it would be really useful - while making a copy of the atom properties in the main thread for other threads to then process certainly works, it does start to get complicated once you have lots of different things all responding to coordinate changes - either they all have to work through a single central dispatch scheme, or stay single threaded, or each make their own copy of the coordinates to work from. So at the moment I only do the map calculations in separate threads, but the geometric validation and restraint visualisation still happens in the main thread. It's generally fast enough so that's OK for now, but there are more things to be added. Sugar validation and restraints, for a start - working over the past week or two with fully-glycosylated models of the spike protein has made me realise just how urgently that's needed - right now, tugging them around leads to some pretty nasty geometry. Nucleic acid validation is also needed, but quite slow/challenging - while rotamer/Ramachandran lookups are pretty straightforward, validation of nucleotide geometry is a 12-dimensional problem requiring some creative approaches to be tractable at all. Having that minimal level of thread-safety would add a lot of flexibility. " enhancement closed moderate Structure Editing wontfix Tom Goddard all ChimeraX