I have a number of worker threads which all perform a flood-fill task on different regions of a bitmap. They all make calls to a recursive sub-routine with different parameters(coordinates). Fyi, I am using a scan-line method. I have implemented a reset feature which aims to kill these processes so that they would start again.

The way I have currently implemented my killing mechanism, is to use a kill Event with manual reset and make the flood-fill subroutine return if it is signaled. This way, the threads will still visit a considerable number of points on the region they are bounded to, before blissfully giving up, but nevertheless skip the relevant filling operation. I was wondering if there is a more efficient way of doing this.

P.S. Yes I know it's an over-kill for flood-fill, but this is a general question. One could imagine a matrix where you would want to perform some expensive local operations based on some local conditions and use a recursive routine of the same nature as an scanline approach.

EDIT: Here is the current design of my framework:

m_pThread[i] = AfxBeginThread(FloodFill_Sub_ThreadProc, (LPVOID)m_pFloodFillInput[i], 0, 0, CREATE_SUSPENDED);

with threadprocedures defined as:

UINT CTestShellDlg::FloodFill_Sub_ThreadProc(LPVOID pData)
FloodFill_Sub(mid, mid, Color_old, Color_new);

and finally the FloodFill_Sub:

void CTestShellDlg::FloodFill_Sub(CPoint& node, CPoint& mid, COLORREF Color_old, COLORREF Color_new) /*Sub-routine to be used by threads*/
if (KillEventTriggered())
if (RecursionTerminationCondition)
//loop some scans and make recursive calls to FloodFill_Sub

Now in the looping section, one could add further KillEventTriggered() checks, But I am wondering if there could be a better approach.


There is no clean and safe way to quickly/efficiently "kill" a thread. You can signal to the thread object that it needs to terminate, but the thread needs to be written in such a way that it checks for this and then cleans itself up. Otherwise, you can end up with partially-completed operations, memory leaks, resource leaks, deadlocks, and all manner of chaos in your program.

Whether or not the threads involved are performing a recursive operation and spawning sub-threads really doesn't change this basic principle.

  • "Whether or not the threads involved are performing a recursive operation and spawning sub-threads really doesn't change this basic principle" I am not sure if I would agree. the fact that the subroutine used is recursive gives a general structure to "check for this and check for that". – Maths noob Dec 18 '14 at 2:54
  • 1
    @Mathsnoob, at the risk of merely repeating what Mason said in a slightly different way, I agree. He's just saying you signal the thread that it's time to die, and it exits on its own, gracefully, rather than you forcefully aborting it from outside. If there's deep recursion going on, it just means there needs to be state (the "signal") that the recursive routine can look at to determine whether to break out of loops or whatever. Pass a "fast exit" variable, leave your subthread with a reference to it so it can signal the recursive routines. Mason is right about the need for clean design here. – Craig Dec 18 '14 at 5:51
  • @Craig This is more of a design question which is why I asked it here, and not stackoverflow. So yeah thanks for reminding me about safe-killing of threads but that's not the point of this question. I have now summarized my current design. Would love to know if it can be made more efficient/clean. – Maths noob Dec 18 '14 at 22:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.