It says that Unity is not thread-safe. What does this exactly imply? If I have a multithreaded C++ DLL that I want to import and use in Unity, is there a procedure to make it compatible?
This is no problem, actually the single-thread limitation is typical for almost all user interface implementations. There are multiple ways how you can solve your problem. I don't know which solution is the best for Unity, I am just providing this as an example how you can proceed: You can for example have a single UI thread and call all Unity-related stuff only from this single thread. Use all other threads for whatever you want and let them communicate with your UI thread. The UI thread is then also de-facto mediator between Unity and the rest of your application.
Related
I am creating simple online chat with server and client in one application. I wrote client-side, but i don't know how will be correct use QTcpServer.
Need i create QTcpServer in new thread? So that I can connect to it as a client from this application. If yes, how do it? Or it's useless and not needed idea?
Need i create new thread for every new connection in order to process it?
I am developing a chat as a course project for a university
Assuming you are using Qt's networking APIs, you don't need to use multiple threads. The reason is that Qt's APIs are designed around a non-blocking event-loop model, so it is expected that no function-call should ever take more than a negligible amount of time (e.g. a few milliseconds) to return, after which the main thread's QEventLoop resumes execution and can therefore handle other tasks in a timely manner, all from within a single thread.
That said, there are a few optional methods in the Qt API that are blocking, and in a single-threaded application, calling those methods risks making your application un-responsive for (however long it takes for those methods to return). Fortunately those methods aren't necessary, and they are clearly documented. I recommend avoiding them, as there are always better, non-blocking ways to achieve the same result in Qt, e.g. by connecting the appropriate signals to the appropriate slots.
To sum up: threads aren't necessary in Qt-based networking, and your program will be simpler, more reliable, and easier to debug if you don't use threads. When implementing server-like functionality, a QTcpServer object is useful; you might want to have a look at this example program for cues on how to use it.
Our software consists of a Graphical User Interface in C++/Qt. The user interface controls several heavy computational algorithms in a separate library which uses C++/OpenMP for parallelization. In this library we cannot use Qt.
To keep our GUI responsive we use function pointers which call QApplication::processEvents();. This of course leads to spaghetti code. We would like to separate the GUI from the computation library, so that the function calls do not block the GUI any longer. What is the clean and prefered way to do this?
If you don't need to interrupt the openMP library calls, then I would go for a simple multi-threading approach: one thread deals with the GUI, another with the computational library. Naturally you cannot use openMP for this (this would not fare well with the computational openMP library), but must use other multi-threading methods. C++11 now comes with its own direct support of threads, so that's what I would do.
EDIT: read Anthony Williams "C++ concurrency in action"
QApplication launches control loop, which calls GUI methods. Naturally, any method taking long will block the queue. To prevent this, you need to spawn additional process/thread via fork/QThread. I think the QThread approach would be the cleanest way to acomplish your goal
I am currently in the process of refactoring an mid-sized software project. It contains a central kernel-like class that is used by multiple threads. Currently, this class uses a Glib::Dispatcher for handling signals that are emitted by multiple threads. Since one goal of the refactoring proccess is to get rid of glibmm entirely (since Qt shall be used as the new framework), I am trying to figure out a way of how to "simulate" the dispatcher functionality using Boost. I already looked into Boost.Signals and Boost.Signals2, but neither one of these libraries seems to offer an alternative to the dispatcher.
To clarify what the dispatcher shall do, here's a short description from the official documentation:
Glib::Dispatcher works similar to sigc::signal. But unlike
normal signals, the notification happens asynchronously through a
pipe. This is a simple and efficient way of communicating between
threads, and especially useful in a thread model with a single GUI
thread.
No mutex locking is involved, apart from the operating system's
internal I/O locking. That implies some usage rules:
Only one thread may connect to the signal and receive notification, but multiple
senders are allowed even without locking.
The GLib main loop must run in the receiving thread (this will be the GUI thread usually).
The Dispatcher object must be instantiated by the receiver thread.
The Dispatcher object should be instantiated before creating any of the
sender threads, if you want to avoid extra locking.
The Dispatcher object must be deleted by the receiver thread.
All Dispatcher objects instantiated by the same receiver thread must use the same main
context.
Could you give me some pointers in the right direction? Is this the sort of functionality I can achieve using Boost.Signals or Boost.Signals2?
Edit: As a commenter rightly pointed out, using Qt would perhaps be an option. However, the class that I am refactoring is very low-level and I do not want to add this additional dependency.
I think there is no simple way to do that, removing Glib in flavour of boost won't solve the problem which is more an architechtural issue than anything else. Replacing with Boost not gonna fix the design issue.
You should model your own signal interface, and try to adapt for each library, including Glib in the first place since it is already working, adding another indirection level to your problem will let you fix that issue.
Boost can help you if you look at boost::function. I dont consider replacing glib with boost to be a real step forward, boost is not a graphical library and it will be required at some point to add an interface with an implementation layer to your graphic engine.
I have now opted for a total rewrite of the class in question. It turns out that I do not require the dispatcher functionality in the way it was provided by Glib. Instead, it was enough to use the normal boost::signals2 signals, coupled with some signals from Qt for the actual graphical interaction.
We have a project with a core functionality implemented using ACE, and architectured around it's Reactor. We want to add a small web interface using Wt.
So the question is, is it possible to replace the main loop of the wt interface with the ace reactor?
The only bad idea that comes to my mind is having a fast timer on the Reactor side which somehow invokes the wt part.
The other way round, the reactor can be run 'tick by tick' using it's handle_events method but I can't find an equivalent on the wt side.
note:
The main concern behind this question is about threads. We don't have threads, the code is not thread safe, and it would be a lot simpler for us if the HMI could be running on the same thread as the rest of the application. But having 2 blocking calls, one to theReactor->run_reactor_event_loop(), and the other to Wt::WRun() is a problem!
That can work with some modifications to the Wt connector. Wt can be compiled without thread support, so in the connector there must be a select() loop of some kind. What you need is the ability to hook into that loop with a timer.
Are you talking about the http connector? That's implemented with boost.asio, so an asio deadline_timer with an async_wait that executes theReactor->run_reactor_event_loop() may be all you need. Maybe you may even find a different idea when you dive into the boost.asio documentation...
It could even work without modifications to the connector. It's not documented, but Server::instance()->service() (in src/http/Server.h) returns you the asio service that you need to implement this.
More info -> Wt's mailing list?
I have discovered through trial and error that the MATLAB engine function is not completely thread safe.
Does anyone know the rules?
Discovered through trial and error:
On Windows, the connection to MATLAB is via COM, so the COM Apartment threading rules apply. All calls must occur in the same thread, but multiple connections can occur in multiple threads as long as each connection is isolated.
From the answers below, it seems that this is not the case on UNIX, where calls can be made from multiple threads as long as the calls are made serially.
From the documentation,
MATLAB libraries are not thread-safe.
If you create multithreaded
applications, make sure only one
thread accesses the engine
application.
When I first started using the engine, I didn't run across any documentation on thread safety, so I assumed that it was not thread-safe.
I use a C++ class to synchronize access to an engine instance. For more parallel processing designs, I instantiate multiple instances of the engine class.
(edit) I'm using MATLAB R14 on Solaris. I open the engine using the 'engOpen' call, and close it using 'engClose'. My platform does not crash when the Close is called by a different thread than the one that called Open.
From a user's perspective, Matlab's interpreter is purely single-threaded. To be safe, you probably need to make all access to the engine from a single thread.
Note that internally, Matlab uses plenty of threads. There are GUI threads, and in the last few versions, the interpreter can use multiple threads behind the scenes. But, the interpreter is semantically equivalent to a single-threaded interpreter (with interrupts).
You can use engOpenSingleUse instead of using engOpen to make more than one thread working separately. (Only Windows)