Multiple Threads ?

[C++Gamer]

Hi there,

I seem to post questions here alot recently, I'll be sure to check back frequently though in order that I can help anyone from my limited knowledge, which will hopefully continue to grow
'Giving back' or some such.

I'll have to go read up on this, but any rough guidance to inform me if this is or is not possible would be great.

I've a webcam running 25fps. I process each image, processing takes almost 1 second. If I program this serially, I'll miss 24 frames each second.

I want to have a thread do the image capture and dump each image internally into a vector. The second thread can process as fast as it can on this ever growing queue (until the image capture stops, then it can work down the backlog).

So I want 2 threads both sharing this vector. Is this ok to do? And if so does anyone have any advice on whether to do it using VC++ functions like _beginthreadex( ) and _endthreadex( ) or to use OpenMP (are both these suitable for this task?)

Thanks for the help, again.

[grumpy]

For creating the thread, you may want to look up the win32 API function CreateThread() [and related functions]

When it comes to accessing an object from two threads, you have a bit of work ahead of you: you need to explicitly synchronise operations so (for example) only one thread is modifying the object at a time, and no thread is trying to read the object state while another is modifying it. If you don't do that, you wind up with various error conditions (the most subtle of which is an object containing data it shouldn't, but no other indication of a problem). To synchronise access to data from multiple threads within one process, look up the function CreateCriticalSection() [and related functions] in the win32 API help file.

Keep in mind that anything involving threads or synchronisation between threads is system dependent. For example, the means of doing things under windows are not necessarily supported under Unix.

[C++Gamer]

Thanks very much for the information.

I'll try and fail not to sound like a moron here, but why is there only 1 match on MSDN relating to CreateCriticalSection ? (which is not a definition of the functions itself but only mentions it).

I also downloaded a Win32 API .hlp and couldn't find it in there either (though CreateThread etc are all there).

Thanks again.

[Ancient Dragon]

see Critcal Sections

[Salem]

With that kind of backlog rate, you may as well just save all the frames to a file, then process that file when you're done recording.

> I want to have a thread do the image capture and dump each image internally into a vector
Have you calculated how much memory per second this will eat up?

> So I want 2 threads both sharing this vector. Is this ok to do?
In theory yes.
But threads are not free, they're not a magic bullet for solving processing problems, and if you make a mess of it, they can be incredibly hard to debug.
At the very least, I'd make sure of a well-tested non-threaded version before trying to thread it.

http://en.wikipedia.org/wiki/KISS_principle

[grumpy]

I'll try and fail not to sound like a moron here, but why is there only 1 match on MSDN relating to CreateCriticalSection ? (which is not a definition of the functions itself but only mentions it).

Because I typed from memory, rather than digging through the win32 API help file. I misnamed the function I had in mind. Try InitializeCriticalSection() instead.

[C++Gamer]

Thanks for all the help and advice. I'm not totally sure what the backlog rate will be at the end, hopefully less than that. It need to be able to process 1 of every 2 frames, storing the second, in order that when its finished (~12 hours) it will be able to process the backlog in the next ~12 hours so it can have data for each day at most a day behind and never falling further behind. I was also thinking it may be an idea to simply save them to a file per image and have a separate program (or thread) read and process the files. An image per file (as opposed to all images in one file) would allow the processing to begin immediately as opposed to waiting until all image capture has completed. The reason I thought threading with an internal vector would be better was the IO overhead of accessing the HDD for every single file, but then this depends on how much RAM the images will chew anyways I guess.

[Salem]

> (~12 hours)
1 frame lost per minute gives you 720 frames over 12 hours.
That sounds like a lot of memory.

You previously said
"I've a webcam running 25fps. I process each image, processing takes almost 1 second."
That's 24 lost per second!

What's changed?


I would suggest that if you can't keep up, then the backlog will kill you because you'll never be in a position to catch up.

while ( 1 ) {
  readImage(buffer);
  processImage(buffer);
}

No threads, no disks.

If that can't keep up, then threads and disks will not make it any better for you.

[Hunter2]

Threads will allow you to perform processing in the background, so that it doesn't block you from capturing new frames at the same time. However, it will not speed the processing up; in fact, it will slow it down (unnoticeably). If you can't process images fast enough now (i.e. acceptable is 1/2 the capture rate, but you have 1/25), threads won't let you process any faster. You'll just have to:
a) Buy a new computer (or a dozen of them)
b) Shorten the capture length
c) Improve the efficiency of your processing algorithm

[jafet]

Threads are not magic silver bullets. Your CPU will always be X Ghz, your disk speed will always be Y rpm, your bus speed will always be Z Mhz. Threads will share the resources, and the overhead asociated with multiple thread management might even slow things down.

c) is probably possible. Try to reduce operations here and there, compile with optimizations and architecture-specific instructions, etc. If you're desperate, there's always assembly!

processing takes almost 1 second

Define "processing". Is the whole second used to do CPU-intensive filtering/blurring? Or is the app stuck for 0.96 seconds on something trival, like disk access queues?

[Salem]

> so that it doesn't block you from capturing new frames at the same time.
Interesting point.
If reading the image is a "slow" process taking 1/25th of a second (like reading directly from the camera), but only using say 5% of the processor in the process, then threads would probably help.

I was assuming that reading the image would be some "fast" block level type access which would be done in say 5mS, thus leaving the other 35mS to process the image.

So C++Gamer, would you characterise access to each image frame as being "fast" or "slow".

[dpro]

Depending on the hardware you are using, cameras can actually be quite slow. Are you allowing the camera to operate in snapshot mode? I am assuming this is more a scientific camera? Or not? Sometimes snapshots can be fast but give you terrible image quality for IA, depending on the setup of course. If you are operating in a movie mode it might not be possible to go much faster than it is working at now. I know in using a scientific camera, using a camera in movie mode ate up lots of time. It would take roughly 700ms to process an image, 550 or so of that was simply waiting for the camera to return the data.

So it really depends also on the mode you are using. This is solely from my own experience, as such, I may be off base, but this is what I've experienced in code.