3

I am working on a C/C++ project which involves a UI and a background service which does some heavy processing by fetching data over the network. In order that my UI doesn't become unresponsive, I would want to spawn a separate thread and then call the background service within that thread, while another thread will display a busy indication in the UI. Once the background service completes it's job, I would want to switch the thread context from background thread to the UI thread, So that the busy indication gets removed and further screen flows can be shown. I believe this is the usual way most of the UI works. What i would want to know is what are the efficient and best ways of achieving this. Right now i do not have a code implemented for the above and I am just asking for ideas and best ways of doing this.

The platform is Linux. The UI framework I am using is a custom UI framework which provides a SDK for UI development but unlike most UI frameworks would it provides nothing for the scenario I mentioned. It is almost deprecated framework but needs to be used for this project which is a pain so only option is I can use Pthread or System v with some wrappers over actual calls which would help me keep the implementation portable on different platforms.

I cannot use Boost Threads because of certain limitations of the embedded environment.
Any suggestions and explanation about how the context switch takes place will be really helpful.

Alok Save
  • 202,538
  • 53
  • 430
  • 533

3 Answers3

6

First, you are confused about how threads work. You can't switch thread contexts at will, the operating system does that whenever it feels like it.

Second, if your concern is context-switch overhead, you are doing something very wrong.

Lastly, UIs usually have event-driven architecture. Usually, you have a "main" thread running an event loop which processes various events. So the proper way to do what you need is to have the background thread post progress events to the "main" thread. And you have to do that in a thread-safe manner; the exact details are dependent on the UI toolkit.

zvrba
  • 24,186
  • 3
  • 55
  • 65
  • I understand the event driver architecture. wherein one would have a event driven mechanism where all threads would post events to the main Q and from there in the main thread removes the events and handles them appropriately, but i don't have this available in my UI framework. One way is to implement something similar but I am looking at better options if possible – Alok Save Nov 09 '10 at 13:36
  • About the context switch, probably my way of putting the premise to words was wrong. Of course OS takes care of allocating time slices to processes..threads...its all non premptive, I do understand that. what i meant is i would want only my UI thread to be handling the UI part meaning UI should be launched within the context of UI thread...my confusing words! – Alok Save Nov 09 '10 at 13:40
  • Does your UI toolkit have a way of handling files/sockets or otherwise monitor a file descriptor ? If not, does it atleast provide some form of timers or recurring event (so you can poll when your thread is done) ? – nos Nov 09 '10 at 14:12
0

I have a sample code to create and use thread and mutex with pthreads. Threads in example concurrently lock mutex/increment variable/unlock mutex. A missing bit which you may need is a conditional variable (same initialization pattern), then will have full set of minimum required primitives for pthread-based implementation of your task runner thread. And you won't depend on any thirdparty library.

bobah
  • 18,364
  • 2
  • 37
  • 70
0

Let me try to help you with a high level answer.

You can indeed look at posix threads (one for UI, one or more for backend processing). You will need to synchronize between them of course; which means also looking at topics such as mutex, volatile keyword or spin lock.

Depending on your degree of comfort with each, try to search for these topics in past questions.

good luck

lemic
  • 177
  • 4