Classification Race Condition about lag HOT 5 CLOSED

This component of the code is a mess. Here's a speculation of how to change it elegantly with minimum work:

The fence in the ProfileWindow class is defined by two Point objects, fenceStart and fenceEnd, stored straight in the Profile class. Modifications to the code could remove fenceStart and fenceEnd from Profile, and instead, anywhere that used them will accept them as a parameter. Now, anywhere calling those functions is making the false assumption that those functions will have access to those values. Those callers must either retrieve those points as a pair from an internal vector, or be passed them by their callers. Compile time errors can assist with this.

A classification thread, once started, can then sequentially retrieve items from this vector (will require a mutex), and stop only when it is empty. This will be based on a method called Profile::getAnyFence, which (locking with the mutex), returns a pair of <fenceStart, fenceEnd>, or a NULL value to indicate to the thread to stop. Profile will only update its internal queue of classifications, and ProfileWindow may only create new ClassifyWorker objects when the one that exists has decidedly stopped.

• Change fenceStart and fenceEnd to a vector of pairs, representing a queue, and also have activeFenceStart and activeFenceEnd points to represent the fence being drawn but not in use, which may change
• Protect this internal queue with a mutex
• Add to this queue when the classify button is clicked
• Subtract from this queue as classification jobs are taken
• Change any function that uses fenceStart and fenceEnd to accept those objects as parameters
• Change the callers of those functions either to be the same or to produce points from the queue or other sources
• ClassifyWorker locks a mutex when it needs to decide whether it is running or not, and to report that fact

from lag.

Implementation in place, closing this thread until it inevitably and hilariously breaks.

from lag.

It's broken! Swapping out the data in the profile while classification is still happening makes for a segfault. Ideally I'd like Profile to store its data better, rather than just resorting to plain and simple arrays, so the code responsible is subject to change at some point. So for now, the code wont be elegant or anything like that, just a check cobbled on somewhere.

from lag.

That's done, for further improvement, a visual cue explaining the problem would be better than the system beep that is currently used to notate abortion of a load_profile event.

On inspection though, it looks like the issue still exists for program termination, it would be good to be able to protect against that, but then again, I'm skeptical about whether it's worth the trouble. This is a case where, for the foreseeable future, time saved by fixing this is less than the time spent doing so. And I would prefer to have a rendering overhaul anyway. And so, I'm closing this.

from lag.

Ammending a race condition by allowing Profile::loadprofile to proceed in some cases. Principally, where the profile only wants to refresh from the quadtree to reflect newly classified points.

from lag.