2 questions about threads

[Dark_Tower]

Hi all, in my application I need to use two different threads:

- The first thread only is executed one time, so, while it's running, the use can only abort it. I have implemented it with a boolean to know if the thread should abort the execution while it's running. This flag can be consulted by the thread while it's running and can be modified by a public method of the thread, all at the same time. I don't use any mutex while I make any of both operations but all works well. Anybody could tell me if it should be better if I use a mutex to lock this shared boolean variable when I consult/modify it?

- The second thread processes some files and can be executed various times. To make it I've thought in 2 different ways: the first ones consists in using a flag to know if the thread should restart in the case that the thread is running and doing QThread::wait at the end of every execution (if it's doesn't need to restart) until it's aborted. But, I've thougth to implement a simpler version that consists in: when the thread is running and the user wants to add more files at the list of the files that the thread is currently processing, I lock the list with a mutex and append the new files at the end of the list. The thread finnishes when it reaches the end of the list. If the user wants to process new files and the thread is finished, it starts again. So with this new version the thread is started everytime (if it's not running), but I don't need the flag to rerstart it and to do wait as on the other version. The question is: what's the best way to implement this last version: in the main bucle of the thread consulting everytime the value count of the list (locking it before with a mutex) to know if it has reached its end, using a Qlistiterator removing the files that has ben processed until the list is empty, or something else? Another question is what's the best way to handle this list of files: with a stringlist containing the path of the files to process or with a list of QFiles to know the path of the files??

Thanks

[high_flyer]

Anybody could tell me if it should be better if I use a mutex to lock this shared boolean variable when I consult/modify it?

Any variable (memory) that can be accessed by more then one thread needs to me mutexed.
The fact its running well is only a matter of luck.
I once coded an application with 6 threads that would crashed every few days... it was a pain in the a** to find the problem.
With if you have not mutexed shared variables, the behaviour is unpredictable.

But I don't understand why do you use threads in the first place.
You have only two tasks, and one is only done once.
In case the the first task needs to run in parallel to the main thread, then you can do it in a thread, but you can do the other task in the main thread, reducing the complexity of your code dramatically.
Don't use threads unless it is absolutly needed.

[Dark_Tower]

Hi high_flyer, I missed to say that both threads doesnt' run at the same time. Each of both runs in different moments of the application. And it's strongly needed a thread for the first case because I need to do a very lengthy operation on background, while in the main thread the user can do another things.

The reason that I don't use a mutex while I consult/modify the shared boolean in the first thread is because these operations are done in just one machine instruction so the cpu never changes the current operating thread while these operations are executed and that's why I think that never could cause a problem, am I wrong?

[Dark_Tower]

Any suggestions for the questions about the second thread?

[high_flyer]

Hi high_flyer, I missed to say that both threads doesnt' run at the same time. Each of both runs in different moments of the application. And it's strongly needed a thread for the first case because I need to do a very lengthy operation on background, while in the main thread the user can do another things.

You don't need a thread for that, you can use processEvents() in your lengthy task.

In general threads are needed when more then one task needs to be executed in prallel.
Is this the case you have?
I am not sure from what you said till now...

The reason that I don't use a mutex while I consult/modify the shared boolean in the first thread is because these operations are done in just one machine instruction so the cpu never changes the current operating thread while these operations are executed and that's why I think that never could cause a problem, am I wrong?

Again, if the cpu stays in one thread, you don't need threads, as threads are used when you want other processes to work in parallel, i.e CPU switches between them.
As answer to what you said, here, is that you can't really know/ have control over what the CPU does so your statmet may or may not be true, depends on the system and your application.

[Dark_Tower]

thanxs high_flyer for your suggestions

[Chicken Blood Machine]

Again, if the cpu stays in one thread, you don't need threads, as threads are used when you want other processes to work in parallel, i.e CPU switches between them.
As answer to what you said, here, is that you can't really know/ have control over what the CPU does so your statmet may or may not be true, depends on the system and your application.

That's not quite true. The setting and getting of his boolean variable will be an atomic instruction and hence thead-safe. He may need a mutex though if he has a function that sets/gets the value and then executes further statements that depend on the value not having changed.

[high_flyer]

What I said is true, and has nothing to do with atomic instructions but with the fact that if the CPU is doing a task (not instruction) where it is not needed to share CPU time with other tasks, threads are not needed.

[Chicken Blood Machine]

I was referring to the second part of your statement, not the first.