threads project dependent

[taylormail]

I have a couple of projects that for whatever reason, I can't seem to get threads to work in. As a test case I'm calling a simple thread function with the following two commands

err = CmtNewThreadPool(20, &POOLHANDLE); 

err = CmtScheduleThreadPoolFunction (POOLHANDLE, MyThreadFunction, NULL, &thread_id);

I do not get an error as a result of either call and the POOLHANDLE and thread_id variables get set to positive non-zero integers so it looks like the functions sort of work, but like I said, it works with some projects and not others and I can't figure out why.

Any thoughts?

[StevieZ]

When you run your simple test example it seems to work correctly without errors. I'm curious on what is happening on those cases where it doesn't work. Do you get errors returned is the CmtStatus return value negative? In addition, have you tried running the Shipping Example multithreading project titled "Simple.cws" (NI Example Finder»Optimizing Applications»Multithreading»Simple.cws) and if you have does this example work correctly?

Regards,

Steven Zittrower

Applications Engineer

National Instruments

http://www.ni.com/support

[taylormail]

I was able to solve the issue by calling ProcessSystemEvents() after the function invocation. I suspect that the reason that it worked in some projects but not in others was pure happenstance. I've seen no recommendation of using ProcessSystemEvents though in any of the app notes, is something else happening here as well?

[menchar]

ProcessSystemEvents allows events from the GUI to execute in callbacks, so if your threads need GUI input to proceed at some point, it could be that was the problem.

Flawed thread behavior is typically just like this - an app may run for days and then the right (wrong?) combination of events and timing exposes the flaw.

Most windowing systems that run on multi-threaded operating systems provide for two types of threads:  worker threads and GUI threads.  A GUI thread is a specialized thread that knows to process GUI events on its own, without you're having to manually inject calls to do so (i.e. process system events).  A worker thread ignores the GUI events.  CVI doesn't provide such a distinction I don't believe, though Windows supports GUI threads and worker threads for the native windowing scheme.  Java does this too.   I wouldn't be surprised but that WinForms in .NET do it too.  You have a GUI thread run the GUI, and worker threads do the work 🙂

If you don't provide for the GUI in your multi-threaded app, then you can see blocky behavior, where the GUI seems to lock up for periods of time.   One way to see this is to grab the window with the mouse and drag it around in quick circles on the desktop - you should see smooth movement, not jerky movement if the GUI is reponsive.

Another place where you see threads get into trouble with the GUI is if you put one or more asleep and nothing is running to keep the GUI active.  Many CVI developers eventually write a "SleepWithEvents" function that allows a thread to sleep but wakes up periodically to process gui events.

Menchar