Design: Progress of Thread Calculations

Hi

This is a general design question.

Say I want to implement some class member functions that perform long term calculations that should be able to report progress. The functions should not use operating system specific code as far as possible, especially, the type of progress report should not be determined!
We may assume a simple "for" loop with "sleep" statements here.

The progress should be displayed in a simple progress dialog that should be reusable for many of such progress reporting functions and offers a "break" button and a status text besides the progress control. The implementation of this dialog is naturally operating system dependent.

The thread should be started by a GUI command from a menu or button on a dialog or whatever.


I know that there are several ways how this can be implemented. I'd like to hear your opinion how this is best implemented. Maybe there are well known good design patterns?

Examples:
1) GUI-command handler creates a (nonmodal) progress dialog, starts the thread and passes the dialog handler to the thread (OS-dependent). GUI must check how long the thread is running. Notification of thread termination is not designed.

2) GUI-command handler creates an OS-specialized progress class (a specialization of a basic progress class that provides virtual functions) that in turn creates the (nonmodal) progress dialog and provide capabilities to send thread-termination notification messages back to e.g. the main application window. GUI-command hander creates the thread and passes a pointer to the specialized progress class to the thread.

3) (ugly!) GUI-command creates modal thread dialog and passed pointer to thread function that should be started. The modal dialog in turn starts the thread and passes its dialog handle (OS-dependent). Thread is responsible for ending modal progress dialog.

Thank you for your ideas

Oliver.

I would do number 2) even if you don't have to be portable. The design is pretty clean and the responsibilities for each class are clearly defined. The thread function only really needs to send messages like set_progress(0.56) or finished_processing() and the progress class only needs to be able send the message cancel() to the thread.

[Moved thread]

Well...I also would suggest point two, however, I also would like to get some additional information.

There are GUI development kits which supports cross-platform development (like Qt, wxWidgets etc.). Thus, a GUI does not have operating system dependent in the first place.

Same applies to the threads...although much more limited there are general threading approaches available like the Boost library.

Hi Yves M & Andreas

Thank you for your suggestions. Yes, from the three examples I do also prefer the second one. But I think it still has some drawbacks:

1) The progress dialog is not modal. After the command handler creates the thread and progress dialog, all other commands have to be disabled. For example, in a frame Window offering 100 Functions, Toolbars etc., all these GUI elements must be disabled (even this is quite simple through the Update-messages). I would not have to worry about this if the progress dialog were just modal.
Is there a way to first create the dialog, then start the thread and make the dialog modal afterwards? without the pitfall that the thread might end before the main thread tries to make the progress dialog modal...

2) The code to start the thread is in a command-handler. The only clean way around this is as far as I see to derive an OS-specific class of the "thread"-class that handles the thread start and creates the progress dialog (on use OS-independent GUI/Thread elements, thank you Andreas). Clean, but not my dream ;)

3) To enable the "break" command, the thread function have to somehow "ask" the dialog whether break was pressed, since the dialog can not notify the (non-"UI") thread. I think this is only possible by using a SendMessage to the dialog (from the OS-specific Progress class) and check the result. This would - as I believe - somewhat unnecessarily slow down the thread. It would be easier if the dialog would know which e.g. boolean variable to flag if a break occurs and the thread would just check this bool.
By typing this, I get the idea to provide the dialog at the thread start with such an address, maybe this would be a solution?

I'm just thinking about some possible design solutions, because I've recently tried some approaches and was not completely satisfied with the design (although it all works seamlessly).

Thanks for the discussion; please let me know if you have any more ideas.

Oliver.

PS: Sorry, Andreas, for posting in the wrong place!

Quote:

---

Originally posted by Oliver Twesten
PS: Sorry, Andreas, for posting in the wrong place!

---

Well...just a short answer in this regard since I am a bit in a hurry...

You do not need to be sorry...the multithreading forum is quite new (some days), thus not known by most of the members... :cool:

Adding theads complicates your program greatly.

The issues you mentioned are the result of moving to multithread
programming.

In a single thread program, these issues do not occur.
In a multithread program, you are required to manage these
by providing the functionality into your program.

The increased complexity is why many multithread programs crash
unexpectedly and without reason. Many of them don't completely
provide the required functionality necessary for multithreads.