Should I go multithreaded ?

[tnarol]

Hi,

I have a thread in charge of refreshing some variables, the thread basically waits for a timer event then does its' job.
Now I'd like to do something else while I refresh the variables, something similar to writing data in a file, but this does not need to be done with the same frequency (10 times slower would be OK).

One thing I imagined is counting the loops in my thread and execute the write thing every 10 loops, but I have the feeling to do something dirty ... Maybe another thread would be better but there is no good reason I see for this. Could you give me your opinion ?

Thanks !

[Siddhartha]

but I have the feeling to do something dirty ... Maybe another thread would be better but there is no good reason I see for this. Could you give me your opinion ? So long as your application in it's current state is working satisfactorily, there is no reason I see to go the multithreaded way for sake of this requirement.

Note that another thread that takes care of writing to the file would need additional synchronization - i.e. you would need to inform it once every 10 loops to carry on and do it's job.

So, I would rather prefer keeping things simple and let things be single threaded as far as possible.

One popular reason to go multithtreaded is when the main-thread gets busy for so long that the UI gets un-responsive. In this case, one dedicated thread takes care of the UI, and the worker thread does the time-intensive job. Note that even in such a case, you would end up with all your functionality in one thread, and the UI nuance in another.

[Andreas Masur]

I have a thread in charge of refreshing some variables, the thread basically waits for a timer event then does its' job.
Now I'd like to do something else while I refresh the variables, something similar to writing data in a file, but this does not need to be done with the same frequency (10 times slower would be OK).

One thing I imagined is counting the loops in my thread and execute the write thing every 10 loops, but I have the feeling to do something dirty ... Maybe another thread would be better but there is no good reason I see for this. Could you give me your opinion ?

Well...I actually would go with the described simple approach. If you already have your thread that does some work and you want to extend the work it should do, I would consider the work being the same logically.

However, if the work is totally unrelated to the currently existing thread (e.g. it does not write the variables to the file), I would consider creating a separate thread for writing to the file instead.

Nevertheless, what is the underlying application in the first place? GUI-based? Console-based?

[tnarol]

Thanks for your answers, I now can see the pro & cons.

My program is currently console based but it will be used as a dll in a larger program that has a GUI.
The second task (that I named "writing a file") has nothing to does with the variables I refresh.

Don't hesitate if you have more comments

[Arjay]

If you are using MFC, you can override OnIdle in your UI thread. OnIdle allows you to perform some 'background' processing while the UI is waiting for user input. It's not really background because it's performed in the same UI thread. This lazy form of processing may work for you, but be aware that if the UI is buzy, the background work won't occur regularly. As mentioned, another approach is to use a separate thread. Often I find that sometimes using a separate thread makes the code cleaner, even after adding the slight overhead of variable synchronization and thread creation. I am sensitive about not going thread creation crazy, but sometimes, you can go overboard with not creating threads, in that you actually end up with code that is more complicated and harder to maintain than it would have been by creating an additional thread.

[sirikrishnap]

Performing the operations in single event handler would be better. Adding two many threads in a dll would not be apt. You can have something like,

static int s_nCount = 0;

call_func1(); // every time
s_nCount++;
if s_nCount >= 20
s_nCount = 0;

swicth(s_nCount)
{
case 0:
case 10:
call_func2(); // every ten times once
break;
case 0:
call_func3(); // every twenty times once
break;
}

[tnarol]

Performing the operations in single event handler would be better. Adding two many threads in a dll would not be apt. You can have something like,

static int s_nCount = 0;

call_func1(); // every time
s_nCount++;
if s_nCount >= 20
s_nCount = 0;

swicth(s_nCount)
{
case 0:
case 10:
call_func2(); // every ten times once
break;
case 0:
call_func3(); // every twenty times once
break;
}

Yes of course. Actually this is the way I do right now, I just wanted to know if calling functions in separate threads would be more efficient or not.

[Andreas Masur]

Yes of course. Actually this is the way I do right now, I just wanted to know if calling functions in separate threads would be more efficient or not.
Well...that higly depends on the target system the code is running on. If this is a single CPU machine, the answer would be no. If this is a multi CPU machine, the answer would most-likely yes - depending on whether multithreading is implemented wisely.

However, despite efficiency there are other reasons to provide e.g. a worker thread to do a certain action.

[fts_technology]

Like people have already said, depends on the computing environment and the problem you are addressing.

Sounds like the variable refreshing and the file writing are not performance-critical. Either approach you take will be fine.

Despite some fear I sense from programmers in general about multithreading, doing what you are trying to do is logically and organizationally cleaner if you put the file writing in a separate thread.

If the variable refresh is performance-critical, I think you'd definitely want file writing in a separate thread. File writing is a time-consuming operation, but it is not CPU-heavy. If you had these two operations in separate threads, during the actual write to disk the OS would schedule CPU time for your other threads to run because the disk-writing doesn't really use CPU. If you had them in the same thread, variable refreshing (or any other CPU-intensive ops) would have to wait

Of course if you used asynchronous or overlapped I/O when doing your file writing then you wouldn't have to stick the file writing in another thread. Overlapped I/O is harder to manage than doing independent synchronous I/O in a background thread, but it does have its advantages, the most notable being scalability.