views:

235

answers:

2

I am working on a program which is essentially single-threaded, and its only thread is the main event-loop thread. Consequently, all its data structures are basically not protected by anything like critical region.

Things work fine until it recently integrates some new functions based on DirectShow API. Some DirectShow APIs open a second event-loop and within that second loop it dispatch messages (i.e. invoke other event-handling callbacks unpredictably). So when a second event-handling function is invoked, it might damage the data struct which is being accessed by the function that invokes the DirectShow API.

I have some experience in kernel programming. And what comes in my mind is that, for a single-threaded program, how it should deal with its data structure is very like how kernel should deal with per-CPU data structure. And in kernel, when a function accesses per-CPU data, it must disable the interrupt (very like the message-dispatching in a second event-loop). However, I find there is no easy way to either avoid invoke DirectShow API or to prevent the create of a second event-loop within them, is there any way?

+1  A: 

mutexes. semaphores. locking. whatever name you want to call it, that's what you need.

Not a good answer.
C. Ross
Mutex, semaphores, locking are for multi-threading. My situation is not a multi-threading but rather re-entry problem.
Middleware
A: 

There are several possible solutions that come to mind, depending on exactly what's going wrong and your code:

  1. Make sure your data structures are in a consistent state before calling any APIs that run a modal loop.
  2. If that's not possible, you can use a simple boolean variable to protect the structure. If it's set, then simply abort any attempt to update it or queue the update for later. Another option is to abort the previous operation.
  3. If the problem is user generated events, then disable the problematic menus or buttons while the operation is in progress. Alternatively, you could display a modal dialog.
Peter Ruderman