I've a foreground service and i'm executing this method:
Controller().threadTest()
Controller().threadTest()
And my Controller class is:
class Controller{
fun threadTest(){
Thread(Runnable{
threadOperation()
}).start()
}
#Synchronized
private fun threadOperation(){
println("Thread start")
Thread.sleep(3000)
println("Thread finish")
}
}
But the #Synchronized isn't working, because my log is:
Thread start
Thread start
Thread finish
Thread finish
What i'm doing wrong?
The #Synchronized annotation only prevents concurrent execution of a function in calls on the same instance. In your case, you are creating two instances of Controller().
You will get the expected behavior (calls execution one-by-one) if you modify the calling code so that it creates only one instance of your class, for example:
val controller = Controller()
controller.threadTest()
controller.threadTest()
Or, if you need mutual exclusion of concurrent calls on multiple Controller instances, you have to either move #Synchronized to another class whose instance both Controllers will reference or use other concurrency utilities, such as withLock calls on a shared lock.
Related
I would like someone to explain to me what is Device.BeginInvokeOnMainThread and what is it for?
And also some examples of cases where it's used.
Just to add an example.
Imagine you have an async method DoAnyWorkAsync if you call it (just as an example) this way:
DoAnyWorkAsync().ContinueWith ((arg) => {
StatusLabel.Text = "Async operation completed...";
});
StatusLabel is a label you have in the XAML.
The code above will not show the message in the label once the async operation had finished, because the callback is in another thread different than the UI thread and because of that it cannot modify the UI.
If the same code you update it a bit, just enclosing the StatusLabel text update within Device.BeginInvokeOnMainThread like this:
DoAnyWorkAsync().ContinueWith ((arg) => {
Device.BeginInvokeOnMainThread (() => {
StatusLabel.Text = "Async operation completed...";
});
});
there will not be any problem.
Try it yourself, replacing DoAnyWorkAsync() with Task.Delay(2000).
The simple answer is: Background thread cannot modify UI elements because most UI operations in iOS and Android are not thread-safe; therefore, you need to invoke UI thread to execute the code that modifies UI such MyLabel.Text="New Text".
The detailed answer can be found in Xamarin document:
For iOS:
IOSPlatformServices.BeginInvokeOnMainThread() Method simply calls NSRunLoop.Main.BeginInvokeOnMainThread
public void BeginInvokeOnMainThread(Action action)
{
NSRunLoop.Main.BeginInvokeOnMainThread(action.Invoke);
}
https://developer.xamarin.com/api/member/Foundation.NSObject.BeginInvokeOnMainThread/p/ObjCRuntime.Selector/Foundation.NSObject/
You use this method from a thread to invoke the code in the specified object that is exposed with the specified selector in the UI thread. This is required for most operations that affect UIKit or AppKit as neither one of those APIs is thread safe.
The code is executed when the main thread goes back to its main loop for processing events.
For Android:
Many People think on Xamarin.Android BeginInvokeOnMainThread() method use Activity.runOnUiThread(), BUT this is NOT the case, and there is a difference between using runOnUiThread() and Handler.Post():
public final void runOnUiThread(Runnable action) {
if (Thread.currentThread() != mUiThread) {
mHandler.post(action);//<-- post message delays action until UI thread is scheduled to handle messages
} else {
action.run();//<--action is executed immediately if current running thread is UI thread.
}
}
The actual implementation of Xamarin.Android BeginInvokeOnMainThread() method can be found in AndroidPlatformServices.cs class
public void BeginInvokeOnMainThread(Action action)
{
if (s_handler == null || s_handler.Looper != Looper.MainLooper)
{
s_handler = new Handler(Looper.MainLooper);
}
s_handler.Post(action);
}
https://developer.android.com/reference/android/os/Handler.html#post(java.lang.Runnable)
As you can see, you action code is not executed immediately by Handler.Post(action). It is added to the Looper's message queue, and is handled when the UI thread's scheduled to handle its message.
You can only update the UI from the main UI thread. If you are running code on a background thread and need to update the UI, BeginInvokeOnMainThread() allows you to force your code to run on the main thread, so you can update the UI.
As explained above, any UI updates must happen in the main thread or an exception will occur.
Though there's a peculiarity with Xamarin.Forms, one can manilpulate UI elements (e.g. create Labels and add them to StackLayout's Children collection) off the main thread without any failures as long as this part of UI is detached from UI elements currently displayed. This approach can be used to boost performance by creating Xamarin.Forms controls and setting their child/parent relations in-memory/off-screen in a separate thread BUT in order to attach them to displayed container (e.g. assign ContentPage's Content property) you will have to do this in Device.BeginInvokeOnMainThread().
While analysing the relationship between UI thread and background thread in some situation, we should be aware of the following:
BeginInvokeOnMainThread method as described in the docs, merely queues the invocation and returns immediately to the caller. So in this case, UI thread and background thread which submitted some work to UI thread, might work in parallel.
However, there is also InvokeOnMainThread which, as described in the docs, waits for the UI thread to execute the method, and does not return until the code pointed by action has completed. So in this case, background thread waits for UI thread to finish executing the given work, and then background thread continues execution.
I'm standing in front of a small (maybe not) problem. I have one function which parses XML file (very big xml ~1Gb) so it takes many time (5-6 mins to finish the func). I don't want to use it in GUI-thread because of known issues (mainwindow freezes and nothing happened, so user thinks everything goes wrong). I've tried to solve this problem by using
QtConcurrent::run
But one more problem appeared: if user press X (close button in top right corner) main GUI-thread goes down, but child-thread which was generated my QtConcurrent::run continue his work and I can kill him only by task manager.
I've decided to use QThread instead of QtConcurrent::run6 but I don't understand how can I run MainWindow class function:
void MainWindow::parseXML()
I've tried to create smth like this:
class pThread : public QThread
{
Q_OBJECT
private:
void run();
};
void pThread::run(){
MainWindow::parseXML();
}
But when I'm trying to compile it error appears:
cannot call member function 'void MainWindow::parseXML()' without object
Moreover, I don't know if it possible to update GUI-thread through this method (parseXML function changes statusBar)
What should I do?
The recommended ways to work with threads in Qt is not to inherit from QThread class, see the documentation here and you should be able to do it after that.
And yes it is possible to update the mainwindow from the thread, just code the signals and slots for that functionality, into mainwindow class code a slot that updates the progress and into the class that does the work (the xml parsing you need - there is no reason that functionality should be into the mainwindow class anyway) you code the signal that emit the progress and connect it with mainwindow's slot with Qt::QueuedConnection (note that the default auto-connection will become queued if the objects are in separate threads).
Another option is to use start a QRunnable with QThreadPool. you may want to check documentation. Be ware to wait the spawned threads with QThreadPool::waitForDone().
I think I might misunderstood several concepts in Qt's threading,
In my window class, which is derived from QWidget:
class Widget
{
Q_OBJECT
public:
Widget::Widget (QObject *parent = 0) : QObject(parent)
{
moveToThread(&th); // still stuck
connect (&th, SIGNAL(started()), SLOT(doWork()));
th.start();
}
private:
QThread th;
private slots:
void doWork ()
{
// hmm, this stuck the UI
while (1)
{
qDebug() << "Sleeping";
}
};
};
The forever loop stuck the UI, it shouldn't be, since that was called by the QThread.
Can anyone point out what's wrong about this code?
Widget::dowork() is executed on the main thread (on which the GUI runs), that's why it blocks. It doesn't matter that it was called by a QThread.
The correct way to execute code on another thread is to first move a QObject instance to a QThread using QObject::moveToThread(), and then connect the started() signal of the QThread to the slot of the QObject instance that you want executed.
If you want to know more: https://www.qt.io/blog/2010/06/17/youre-doing-it-wrong
Another issue with your code is that you're trying to move a QWidget-derived object to another thread. This is not allowed. QWidget instances must remain on the main thread. Instead, you should subclass from QObject.
Yet another issue with the code is that you're doing this in the constructor. Moving the object to another thread while it's not fully constructed yet is just asking for trouble.
If an object of type QObject is moved to a thread with QObject::moveToThread, all signals that the object receives are handled inside that thread. However, if a slot is called directly (object->theSlot()) that call will still block. What would be the normal way of executing that call inside the thread and returning control to the calling thread immediately? Hacks with QTimer don't count. Setting up a single purpose connection and deleting it again might count as a solution if all else fails.
You could use QMetaObject::invokeMethod with Qt::ConnectionType set to Qt::QueuedConnection
You can use QFuture<T> QtConcurrent::run ( Function function, ... ) to launch some execution inside a separate thread and then use QFutureWatcher to get the result. You will not need to call movetoThread.
Basically something like :
QFutureWatcher<T>* watch = new QFuture(0);
connect(watch, SIGNAL(finished()), this, SLOT(handleResult()));
QFuture<T> future = QtConcurrent::run( myObj, &QMyObject::theSlot(), args...);
watch.setFuture(future);
....
//slot
private void handleResult(){
if(future->isCancelled())
return;
T mydata = watch->future()->result();
// use your data as you want
}
QtConcurrent::run will schedule the method of this object to be ran in some thread. It is non-blocking. On the other hand, QFuture::result() blocks until there is a result, if the computation is still ongoing. That's why you need the other object to notify when the computation is over using finished(). I cannot think of a better design for your problem in Qt.
I'm a QT newbie. I have a class extend from widget like:
class myclass: public Qwidget
{
Q_OBJECT
public:
void myfunction(int);
slots:
void myslot(int)
{
//Here I want to put myfunction into a thread
}
...
}
I don't know how to do it. Please help me.
Add a QThread member then in myslot move your object to the thread and run the function.
class myclass: public Qwidget
{
QThread thread;
public:
slots:
void myfunction(int); //changed to slot
void myslot(int)
{
//Here I want to put myfunction into a thread
moveToThread(&thread);
connect(&thread, SIGNAL(started()), this, SLOT(myfunction())); //cant have parameter sorry, when using connect
thread.start();
}
...
}
My answer is basically the same as from this post: Is it possible to implement polling with QThread without subclassing it?
Your question is very broad . Please find some alternatives that could be beneficial to you :
If you want to use signal/slot mechanism and execute your slot within a thread context you can use moveToThread method to move your object into a thread (or create it directly within the run method of QThread) and execute your slot within that thread's context. But Qt Docs says that
The object cannot be moved if it has a
parent.
Since your object is a widget, I assume that it will have a parent.
So it is unlikely that this method will be useful for you.
Another alternative is using QtConcurrent::run() This allows a method to be executed by another thread. However this way you can not use signal/slot mechanism. Since you declared your method as a slot. I assumed that you want to use this mechanism. If you don't care then this method will be useful for you.
Finally you can create a QThread subclass within your slot and execute whatever your like there.
This is all I could think of.
I hope this helps.