I have a C++ program that captures videos, and I would like to be able create a command-line program to update its frame rate, image format, etc on the fly.
How can I do this without halting the entire program? I need it to be able to wait for user input, but still capture videos at the same time. I know this will probably involve some kind of multi-threading, which I am entirely new to. Some suggestions/links would be nice.
Than you all,
Are you developing this for a specific platform or does it need to be platform independent?
If you are developing for windows you should look into the win32 API. specifically beginthread or _beginthreadex on msdn
I'm not too familiar with *nix development but pthreads i believe would do the trick and can be used in Windows and *nix
Another option would be to use the BOOST libraries. BOOST can be used on Windows and *nix systems. Below is a link to the BOOST Thread documentation.
http://www.boost.org/doc/libs/1_44_0/doc/html/thread.html
I find BOOST Threads a lot easier to use than WIN32 Threads and at the same time you're not tied down to a specific platforms API.
Create a thread to handle video, whilst using the main thread to wait for input. Thread creation depends on platform, and can be a little overwhelming to those who are new. You will need a mutex on variables that can be altered through the command line, and you'll need to look up of how to make your code "thread safe".
In the days before multi-threading it was possible to solve this as well by regularly peeking into the keyboard buffer from time to time. I mention this just as an alternative to opening the multi-threading box which often gives you more than you bargain for.
EDIT: I read now a bit more carefully what you want to achieve, having a console program to update another program with new settings. I think what you then need is for the programs to communicate with one another. Look at boost::interprocess for that.
Related
I will sketch the scenario I would like to get working below.
I have one main application.
That application, based on user interactions, can load other applications inside a secure environment/shell. This means these child applications cannot interact with the OS anymore, nor with each other.
The parent program can at any time call functions of these child programs.
The child program can at any time call functions of these parent programs.
Does anyone know how to implement this in C++? Preferably both parent and child should be written in C++.
The performance of loading the child applications inside the parent application doesn't matter. The only thing that matters is the performance of the communication between child and parent when calling functions of each other.
You will have to write your own compiler.
Consider: No normal OS supports what you want. You want both executables to run inside a single process, yet that process may or may not make OS calls depending on some weirdness inside the process which the OS doesn't understand at all.
This is no longer a problem with your custom compiler, as it simply will not create the offending instructions. It's similar to Java and .Net, which also prevent such OS calls outside their control.
A portable solution: Google Native Client
One possible Linux solution:
Make AppArmor profile with "hats" (a "hat" is a sandboxing configuration to which the application can switch programmatically with libapparmor),
have the main application create a "pipe",
have the main application "fork",
change into a "hat" corresponding to the child application,
"exec" the child application,
the main application and the child application communicate via the "pipe" created earlier.
If you want a (semi)crossplatform way to do this you can use RPC to call functions in another process. It's going to work on anything that supports the distributed computing environment. It's been around for some time and the msdn documentation states that parts of windows use it for inter process communication so it's probably fast enough. Here's a tutorial on msdn that should get you up and running http://msdn.microsoft.com/en-us/library/windows/desktop/aa379010.aspx The bad part is that I haven't been able to find a tutorial about using it on linux.
If you don't want to use RPC or find it too hard to find good documentation on the subject, you can use the standard IPC(Inter Process Communication) mechanisms from unix systems to signal your process that should call a certain function. I'd recommend a message queue because it's very fast and lightweight. You can find a tutorial here: http://www.cs.cf.ac.uk/Dave/C/node25.html
I am not familiar with OS restrictions in above answers. However, I found an easy way to solve this problem. I hope it helps and does not have a technical issue. I used Linux OS. Suppose I want to call C++ program B inside another C++ program A. I wrote a perl script (such as PerlScript.pl) that contains a system call to run program B. Then in A, I did a system call like system("perl PerlScript.pl") that ask perl to run B for me.
I have a GNU Radio application which utilizes both Python and C++ code. I want to be able to signal the C++ code of an event. If they were in the same scope I would normally use a simple boolean, but the code is separate to the point where some form of shared memory is required. The code in question is performance-critical so an efficient method is required.
I was initially thinking about a shared memory segment that is accessible by both Python and C++. Therefore I could set a flag in the python code and check it from C++. Since I just need a simple flag to pause the C++ code, would a semaphore suffice?
To be clear, I need to set a flag from Python and the C++ code will simply check this flag, and if it is set enter a busy loop.
So would trying to implement a shared memory segment between Python/C++ be a reasonable approach? How about a semaphore? On Linux, which is easier to implement?
Thanks!
Assuming this is two separate applications on one machine and you need decent real time performance you don't want to go with sockets. I would use a flag in shared memory, and probably use a semaphore to make sure both programs can't be accessing the flag at once. This library provides access to the semaphores and shared memory with Python and supports Python versions 2.4-3.1 (not 3.0): http://semanchuk.com/philip/posix_ipc
EDIT: Changed recommendation to using a semaphore protecting the flag in shared memory
Why not open a unix socket? Or use DBus
If Boost is an option, you could use Boost.Python and Boost.Interprocess. Boost.Python gives you a way for Python & C++ objects to interact and Boost.Interprocess gives you plenty of options for shared memory or synchronization primitives across process boundaries.
DBus looks promising. It supports signals, so you should be able to stop an application on demand. However, I'm not sure if it's performance will be enough for you.
You can try using custom signals. I don't know about Python code being able to send custom signals, but your C/C++ can certainly define custom signals with SIGIO.
If you have stringent response-time requirements, you might need to look beyond your application code and into some time of OS with support for real-time signals (rt-linux, muOs, etc.)
I was recently making a very simple application that just printed matrix-effect out to the console. So I made it in a very easy to use function void drawLine(int startX, int startY, int lineLength,int speed);. The problem now is that it only prints one line at a time. Of course I need to make this application multi-threaded, but I found myself struggling because I've never done this in C++, only in C# and in C# it is very easy to do compared to C++.
I did some research and tried to create 3 threads with CreateThread and then launching them with WaitForMultipleObjects. But output is very weird and doesn't seem correct. And it also leads me to next problem even if this would work correctly. Imagine that I want to launch 15+ lines on my console, does that mean that I need to create 15 different threads?
Note that this is not something important, it's just something I just created because I was bored and also because I want to learn threading with C++. I can, of course use boost libraries, but I want to create example for myself w/o using it.
Here is a screenshot with 1 thread only just to make it more clear:
This problem has nothing to do with threading- or rather, this problem absolutely doesn't require threading. A simple object-orientated design should easily allow you to draw multiple lines in a frame- how do you think single-threaded games draw thousands or more of vertices in a frame?
More importantly, only recent (Windows Vista or later) renderers for Windows allow multi-threaded rendering- that is, Direct2D/Direct3D11. Other renderers like D3D9 hold internal locks that prevent multi-threaded rendering because their run-times and the graphics drivers can't handle it.
If you do have a concurrency-safe renderer like Direct2D, then it should be relatively trivial to render from multiple threads- and you shouldn't be using the native Windows threading API. I see that you're using Visual Studio 2010- use the Concurrency runtime. The WinAPI only provides threading primitives- using them directly would be akin to writing in assembler. At least use boost::thread. Threading is not really about implementation, it's about good design, and design is irrelevant of what library you use to implement it.
Edit: Wait a minute, you're using the console? That's not thread-safe at all. That's insanity. The console exists for the most basic I/O ever, not for this. What's most likely is that C# just synchronizes it for you and C++ doesn't.
The function drawLine is probably one loop with a command to position the cursor, following with printing the character (if not then show us the function code). Those two instructions must execute sequentially, without some other instruction from other thread messing with the execution. So, introduce a lock (AKA critical section) that will guarantee that these two instructions execute orderly. Order of functions would be something like this:
EnterCriticalSection
SetConsoleCursorPosition
SetConsoleTextAttribute
WriteConsole
LeaveCriticalSection
The critical section is shared among all threads.
Single threaded approach is also an option, because the matrix strings don't interact. Simple solution would be something like this: Keep in memory data of all matrix strings, and just draw them one after another, in single thread. Sleep a little after all strings are drawn. Hopefully, the animation will look plausible.
More complex solution would be to use simple solution, but to have two screen buffers (with CreateConsoleScreenBuffer and SetConsoleActiveScreenBuffer), and switch them constantly to achieve instant drawing.
I am looking for a cross-platform C++ master/worker library or work queue library. The general idea is that my application would create some sort of Task or Work objects, pass them to the work master or work queue, which would in turn execute the work in separate threads or processes. To provide a bit of context, the application is a CD ripper, and the the tasks that I want to parallelize are things like "rip track", "encode WAV to Mp3", etc.
My basic requirements are:
Must support a configurable number of concurrent tasks.
Must support dependencies between tasks, such that tasks are not executed until all tasks that they depend on have completed.
Must allow for cancellation of tasks (or at least not prevent me from coding cancellation into my own tasks).
Must allow for reporting of status and progress information back to the main application thread.
Must work on Windows, Mac OS X, and Linux
Must be open source.
It would be especially nice if this library also:
Integrated with Qt's signal/slot mechanism.
Supported the use of threads or processes for executing tasks.
By way of analogy, I'm looking for something similar to Java's ExecutorService or some other similar thread pooling library, but in cross-platform C++. Does anyone know of such a beast?
Thanks!
I haven't used it in long enough that I'm not positive whether it exactly meets your needs, but check out the Adaptive Communications Environment (ACE). This library allows you to construct "active objects" which have work queues and execute their main body in their own threads, as well as thread pools that can be shared amoung objects. Then you can pass queue work objects on to active objects for them to process. Objects can be chained in various ways. The library is fairly heavy and has a lot to it to learn, but there have been a couple of books written about it and theres a fair amount of tutorial information available online as well. It should be able to do everything you want plus more, my only concern is whether it possesses the interfaces you are looking for 'out of the box' or if you'd need to build on top of it to get exactly what you are looking for.
I think this calls for intel's Threading Building Blocks, which pretty much does what you want.
Check out Intels' Thread Building Blocks library.
Sounds like you require some kind of "Time Sharing System".
There are some good open source ones out there, but I don't know
if they have built-in QT slot support.
This is probably a huge overkill for what you need but still worth mentioning -
BOINC is a distributed framework for such tasks. There's a main server that gives out tasks to perform and a cloud of workers that do its bidding. It is the framework behind projects like SETI#Home and many others.
See this post for creating threads using the boost library in C++:
Simple example of threading in C++
(it is a c++ thread even though the title says c)
basically, create your own "master" object that takes a "runnable" object and starts it running in a new thread.
Then you can create new classes that implement "runnable" and throw them over to your master runner any old time you want.
I have been a C programmer for many years and my favorite "debugger" has always been the printf() function - I only resort to visual studio's debugger when absolutely forced and so have never been very proficient in using it. Recently I have had to modify a program from C to C++ (although of course printf still works fine) and and parts of the program are now farmed out in to multiple threads (one for each core on a multicore machine) to make the program run faster. Now i will no doubt come up against awkward multi-thread related bugs like deadlocks and I wonder what debugging methodology I can turn to. Does visual studio (2008) have everything I could reasonably need to help me resolve thread related bugs? Should I take some time out now to learn how to use some third party debugger? Could I solve most problems using my good old printf?
Could I for example write code which, if kept waiting on entry to a critical section would print something like "Thread X waiting to enter ... but blocked because its being used by thread Y"?
Visual Studio supports thread debugging to some extend. Via the Threads Window you can select threads, suspend and resume threads etc. When you switch between threads the Call Stack Window is updated accordingly so you can inspect what each thread is doing. You may also restrict breakpoints to specific threads.
If you want an alternative WinDbg (which is part of the free Debugging Tools for Windows package from Microsoft) offers lots of options as well but with a slightly more esoteric user interface.
As for using printf, there's the problem of synchronizing output. If you don't do it you output will most likely be gibberish. If you do synchronize it you basically change the concurrency of the application, which may or may not affect the problem you're trying to solve.
If you could port your project to Linux, Valgrind (especially the 'helgrind' tool) would do exactly what you ask. http://valgrind.org/
I'm not sure if this is exactly what you are asking, but, To help in debugging, you can write code that gives each thread a "name", so that debug messages printed to the debug window, (or a log file or whatever) include that thread "name" along with whatever other info you prescribe. The code below is in C# but this is available even in unmanaged C++
Thread T = new Thread(RunSchedule);
T.Name = "Scheduler"; // <=== Thread given a name here...
T.Start();
Intel provides several tools to find out threading-related issues: data races, deadlocks, performance penalties. These tools are: Intel Thread Checker, Intel Thread Profiler.