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.
Related
I'm designing the threading architecture for my game engine, and I have reached a point where I am stumped.
The engine is partially inspired by Grimrock's engine, where they put as much as they could into LuaJIT, with some things, including low level systems, written in C++.
This seemed like a good plan, given that LuaJIT is easy to use, and I can continue to add API functions in C++ and expand it further. Faster iteration is nice, the ability to have a custom IDE attached to the game and edit the code while it runs is an interesting option, and serializing from Lua is also easy.
But I am stumped on how to go about adding threading. I know Lua has coroutines, but that is not true threading; it's basically to keep Lua from stalling as it waits for code that takes too long.
I originally had in mind to have the main thread running in Lua and calling C++ functions which are dispatched to the scheduler, but I can't find enough information on how Lua functions. I do know that when Lua calls a C++ function it runs outside of the state, so theoretically it may be possible.
I also don't know whether, if Lua makes such a call that is not supposed to return anything, it will hang on the function until it's done.
And I'm not sure whether the task scheduler runs in the main thread, or if it is simply all worker threads pulling data from a queue.
Basically meaning that, instead of everything running at once, it waits for the game state update before doing anything.
Does anyone have any ideas, or suggestions for threading?
In general, a single lua_State * is not thread safe. It's written in pure C and meant to go very fast. It's not safe to allow exceptions go through it either. There's no locks in there and no way for it to protect itself.
If you want to run multiple lua scripts simultaneously in separate threads, the most straightforward way is to use luaL_newstate() separately in each thread, initialize each of them, and load and run scripts in each of them. They can talk to the C++ safely as long as your callbacks use locks when necessary. At least, that's how I would try to do it.
There are various things you could do to speed it up, for instance, if you are loading copies of a single script in each of the threads, you could compile it to lua bytecode before you launch any of the threads, then put the buffer into shared memory, and have the scripts load the shared byte code without changing. That's most likely an unnecessary optimization though, depending on your application.
I'm taking my first steps in GTK+ (C++ and gtkmm more specificaly) and I have a rather conceptual doubts about how to best structure my program. Right now I just want my GUI to show what is happening in my C++ program by printing several values, and since my main thread is halted while the GUI window is running, I've come across solutions that separated both the processing/computing operations and the graphical interface in separate threads. Is this commonly accepted as the best way to do it, not at all, or not even relevant?
Unless you have a good reason, you are generally better off not creating new threads. Synchronization is hard to get right.
GUI programming is event driven (click on a button and something happens). So you will probably need to tie your background processing into the GUI event system.
In the event that your background processing takes a long time, you will need to break it into a number of fast chunks. At the end of each chunk, you can update a progress bar and schedule the next chunk.
This will mean you will need to probably use some state machine patterns.
Also make sure that any IO is non-blocking.
Here's an example of lengthy operation split in smaller chunks using the main loop without additional threads. Lazy Loading using the main loop.
Yes, absolutely! (in response to your title)
The GUI must be run in a separate thread. If you have ever come across those extremely annoying interfaces that lock up while an operation is in progress1, you'd know why it's very important to have the GUI always running regardless of operation happening.
It's a user experience thing.
1 I don't mean the ones that disable some buttons during operation (that's normal), but the ones that everything seems frozen.
This is the reverse: the main thread should be the Gtk one, and the long processing/computing tasks should be done in threads.
The documentation gives a clear example:
https://pygobject.readthedocs.io/en/latest/guide/threading.html
I wrote a tool in C++ using wxWidgets for the GUI and IBM ILOG Cplex to solve an optimization problem.
In one of the functions called by the wx event handler, I invoke the IBM ILOG Cplex Optimizer which is itself multi-threaded code.
I realize that this causes indererministic bugs with non-sensical memory contents.
Since I have no experince in writing multi-threaded code and would like to get away without spending three weeks learning how to do it, I would like to know:
Is there is some safe, possibly inelegant way to avoid problems here? (More elegant, maybe, than writing a file to disc, calling a different task through the OS and reading the output back in).
Is it a bad idea to launch Cplex threads from a wx thread?
Is it generally a bad idea to use two libraries that might use different libraries internally to implement multi-threading? (I have no idea what there is except pthreads and what is used by either cplex or wx).
Any help and background information is appreciated.
Based on my experience, the rule is:
every wxWdiget function call that change the display must be made in the wxWidget thread
I don't know much about Cplex, but if you say it's multithreaded, chances are you are calling an asynchronous function and you handle the results in a call back. The callback is most definitely not called withing the wxWidget thread. If you then try to display the results within the callback, you are breaking the rule stated above. That's when you'll get nice little bugs, which in my case usually materialize as heap corruption.
To fix that you must pass the results of your callback to the wxWidget thread and display them in that thread. There's many way to do it, but the global mechanism is to trigger a custom event on wxWigdet that get passed to the wxWidget thread.
Check this link, http://wiki.wxwidgets.org/Custom_Events you need to use
wxEvtHandler::AddPendingEvent(wxEvent& event)
I have a project and I want to convert it to multi-threaded application. What are the things that can be done to make it a multi threaded application
List out things to be done to convert into multithreaded application
e.g mutex lock on shared variables.
I was not able to find a question which list all those under single hood.
project is in C
Single threaded application need not be concerned about being thread safe.
This issue arises when you have multiple threads which are trying to access a commonly shared resource. At that time, you must be concerned.
So, no need to worry.
EDIT (after question been edited ) :
You need to go through the following links.
Single threaded to multithreaded application
Single threaded to multithreaded application - What we need to consider ?
Advice - Single threaded to multithreaded application
Also a good advice for converting single to multithreaded application.Check out.
Single threaded -> Multithreaded application :: Good advice.
The big issue is that, in general, when designing your application it is very difficult to choose single thread and then later on add multi-threading. The choice is fundamental to the design idioms you are going to strive towards. Here's a brief but poor guide of some of the things you should be paying attention towards and how to modify your code (note, none of these are set in stone, there's always a way around):
Remove all mutable global variables. I'd say this goes for single threaded applications too but that's just me.
Add "const" to as many variables as you can as a first pass to decide where there are state changes and take notes from the compilation errors. This is not to say "turn all your variables to const." It is just s simple hack to figure out where your problem areas are going to be.
For those items which are mutable and which will be shared (that is, you can't leave them as const without compilation warnings) put locks around them. Each lock should be logged.
Next, introduce your threads. You're probably about to suffer a lot of deadlocks, livelocks, race conditions, and what not as your single threaded application made assumptions about the way and order your application would run.
Start by paring away unneeded locks. That is, look to the mutable state which isn't shared amongst your threads. Those locks are superfluous and need to go.
Next, study your code. At this point, determining where your threaded issues are is more art than science. Although, there are decent principals about how to go about this, that's about all I can say.
If that sounds like too much effort, it's time to look towards the Actor model for concurrency. This would be akin to creating several different applications which call one another through a message passing scheme. I find that Actors are not only intuitive but also massively friendly to determining where and how you might encounter threading issues. When setting up Actors, it's almost impossible not to think about all the "what ifs."
Personally, when dealing with a single threaded to multi threaded conversion, I do as little as possible to meet project goals. It's just safer.
This depends very heavily on exactly how you intend to use threads. What does your program do? Where do you want to use threads? What will those threads be doing?
You will need to figure out what resources these threads will be sharing, and apply appropriate locking. Since you're starting with a single-threaded application, it's a good idea to minimize the shared resources to make porting easier. For example, if you have a single GUI thread right now, and need to do some complex computations in multiple threads, spawn those threads, but don't have them directly touch any data for the GUI - instead, send a asynchronous message to the GUI thread (how you do this depends on the OS and GUI library) and have it handle any changes to GUI-thread data in a serialized fashion on the GUI thread itself.
As general advice, don't simply add threads willy-nilly. You should know exactly which variables and data structures are shared between threads, where they are accessed, and why. And you should be keeping said sharing to the minimum.
Without a much more detailed description of your application, it's nearly impossible to give you a complete answer.
It will be a good idea to give some insight in your understanding of threading aswell.
However, the most important is that each time a global variable is accessed or a pointer is used, there's a good chance you'll need to do that inside of a mutex.
This wikipedia page should be a good start : http://en.wikipedia.org/wiki/Thread_safety
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.