id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	blockedby	blocking	notify_on_close	platform	project
1024	Add infrastructure such as locks to support C++ thread use	Tristan Croll	Tom Goddard	"At the moment this is mostly for the purpose of planning ahead rather than something I plan to use heavily immediately, but I've been playing around with how performance of ISOLDE (particularly all the live validation) might be improved with C++ threading - since it's pretty clear that Python threading is never going to cut it for VR-level performance.

Basically, the general idea is to kick off (a) thread(s) at the point coordinates are updated from the simulation, and defer application of the results to a later frame. I came up with the attached method which works nicely in my test case (pushing rotamer validation to a std::thread - see the bits labelled /*****TESTING****/ in the attached rota.h/cpp if you want to see the internal logic). Basically, it takes handles to three functions (one to start the thread, one to check if it's done, and one to finalise it and apply the results), and arguments to the initialisation and finalisation functions. It then calls the initialiser, and adds a callback to the 'new frame' trigger which runs the check function and if it returns true, runs the finalisation and removes its own handler. I can have the HIV capsid rotating on screen with full lighting, and run rotamer validation (which takes about half a second) without even a momentary glitch in framerate.

At present this approach would obviously have to be used with a lot of care. Since there are no mutex's on anything, there's nothing to stop atoms being changed (or, more disastrously, deleted) while such a thread is running. That being said, I'm fairly confident I can use it safely in ISOLDE (in the specific context of running simulations) with no changes to the ChimeraX core. In that case I know that coordinates won't be updated more than once per 100ms (at present, at least), each individual validation task is <5ms, and I'll only ever be reading from ChimeraX objects, not writing to them.

Still, I'm wondering: is there any long-term plan to make the core ChimeraX objects thread-safe? It would be great to have a multiple-reader/single-writer mutex arrangement in place for peace of mind."	enhancement	closed	moderate		Performance		not a bug		Eric Pettersen Conrad Huang Greg Couch				all	ChimeraX