Note note = new Note(400,"short");
note.start(); //start the note thread
Vs
new Note(400,"short").start();
I thought both ways are same to make instance of the class. But only the first way above moves my note with thread... what's the difference between those two and why thread start method only works with the first one?
Related
I have the same situation like this: stop thread started by qtconcurrent::run
I need to close child thread (started with QtConcurrent::run) on closeEvent in QMainWindow.
But my function in child thread use code from *.dll: I can`t use loop because all that I do - is calling the external dll like
QFuture<void> = QtConcurrent::run(obj->useDllfunc_with_longTermJob());
And when I close the app with x-button my gui is closed, but second thread with_longTermJob() still worked and when is finished I have an error.
I know some decisions for this:
using other functions like map() or something else with
QFuture.cancel/stop functionality, not QtConcurrent::run().But I need only one function call. run() is what I need.
or use QThread instead Concurrent.But it`s not good for me.
What method more simple and better and how can I implement this? Is there a method that I don`t listed?
Could you provide small code sample for decision. Thx!
QtConcurrent::run isn't a problem here. You must have means of stopping the dllFuncWithLongTermJob. If you don't have such means, then the API you're using is broken, and you're out of luck. There's nothing you can do that'd be generally safe. Forcibly terminating a thread can leave the heap in an inconsistent state, etc. - if you need to terminate a thread, you need to immediately abort the application.
Hopefully, you can call something like stopLongTermJob that sets some flag that interrupts the dllFuncWithLongTermJob.
Then:
auto obj = new Worker;
auto objFuture = QtConcurrent::run([=]{obj->dllFuncWithLongTermJob();});
To interrupt:
obj->stopLongTermJob(); // must be thread-safe, sets a flag
objFuture.waitForFinished();
I've been trying to implement a thread that runs in the background and updates a progress bar every second or so and following the example in the top answer to Delphi - timer inside thread generates AV. I notice that the proposed solution has an implementation of TThread.FinishThreadExecution. My IDE shows that my version of delphi supports that method, but I've been unable to find any documentation on it (google turns up 10 hits, none of which help, http://docwiki.embarcadero.com/ doesn't list that method under TThread. What is it for and when is it called?
FinishThreadExecution is not a method inherited from the TThread base class. It is only a method implemented in the derived class, TTimerThread.
The purpose of the method is to finish the execution of the thread in a proper way.
All FinishThreadExecution does is to call Terminate, which sets an internal flag in the TThread, plus sets the FTickEvent event to wake the thread. The thread execute method will then end and the thread will self destruct, since TThread.FreeOnTerminate is true.
ABAddressBookRef can only be accessed by one thread. I think a good model would be having a thread for ABAddressBookRef in the background, besides the main thread.
How can I ensure that there's only one thread while using NSOperationQueue? Simply setting max concurrency to 1 won't guarantee it to be run on the same thread.
Should I use other unique threads like web threads?
You can manually create a thread and redirect all address book access to it.
You create a thread with something like this (adapted from documentation):
NSThread* myThread = [[NSThread alloc] initWithTarget:[MyThread new]
selector:#selector(myThreadMainMethod)
object:nil];
[myThread start]; // Actually create the thread
Note that for the thread to be useful, you have to implement a run loop in thread's main method.
See example implementation of run loop in this answer.
You are then able to do stuff on this thread using the NSObject's method performSelector:onThread:withObject:waitUntilDone:.
Here's a wrapper library for ABAddressBookRef that implements this concept – RHAddressBook.
So basically the situation I am in is I have a bunch of threads each doing different calculations throughout the week. At the end of the week, every thread calls function X() and then starts calculating for the next week and repeats this cycle.
However, only one thread is allowed to actually do the operations in method X() and only when all threads have reached method X(). Furthermore, none of the threads can continue on their way until the one thread that got to use method X() is finished.
So I'm having difficulty implementing this. I feel like I need to use a condition variable but I'm still shaky with threads and whatnot.
Barriers are a useful synchronization method here.
In pthreads, you can use two barriers, each initialized to a require however many threads are running. The first synchronizes threads after they've finished calculating, and the second after one of them has called X(). Conveniently, the pthread_barrier_wait will elect one and only one of your N waiting threads to actually call X():
void *my_thread(void *whatever) { // XXX error checking omitted
while (1) {
int rc;
do_intense_calculations();
// Wait for all calculations to finish
rc = pthread_barrier_wait(&calc_barrier);
// Am I nominated to run X() ?
if (rc == PTHREAD_BARRIER_SERIAL_THREAD) X();
// Wait for everyone, including whoever is doing X()
rc = pthread_barrier_wait(&x_barrier);
}
Java's CyclicBarrier with a Runnable argument would let you do the same thing with but one barrier. (The Runnable is run after all parties arrive but before any are released.)
They seem to perform a reasonably similar task: launching a new thread that performs that selector quickly and easily. But are there any differences? Maybe with regards to memory management?
Both are identical.
In iOS and Mac OS X v10.5 and later, all objects have the ability to spawn a new thread and use it to execute one of their methods. The performSelectorInBackground:withObject: method creates a new detached thread and uses the specified method as the entry point for the new thread. For example, if you have some object (represented by the variable myObj) and that object has a method called doSomething that you want to run in a background thread, you could could use the following code to do that:
[myObj performSelectorInBackground:#selector(doSomething) withObject:nil];
The effect of calling this method is the same as if you called the detachNewThreadSelector:toTarget:withObject: method of NSThread with the current object, selector, and parameter object as parameters. The new thread is spawned immediately using the default configuration and begins running. Inside the selector, you must configure the thread just as you would any thread. For example, you would need to set up an autorelease pool (if you were not using garbage collection) and configure the thread’s run loop if you planned to use it. For information on how to configure new threads
I presume they are the same, as - (void)performSelectorInBackground:(SEL)aSelector withObject:(id)arg; is defined in NSThread.h in the NSObject (NSThreadPerformAdditions) category. That is nothing conclusive, but that is evidence in that direction.