Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.

speed up GIS

bicealyh
Beginner
158 Views
Higuy,
my Master'sthesis is about touseTBBto speed upthe display ofgeographic informationsystem data.

Display ofgeographic information systemscan beformed with multiplerelatively independentlayers, so I can use the Intel TBB draw each layer and then return thepainting layer just like the bmp image format.Finally,combination of thesepainting layer into a map.
I have see theGUIdesign patternsbut I don't know how to do with it.When the userthrough theGUIoperate the Map(just like zoom in), the Intel TBB must quickly stop the lastoperate, return the Partial resultand execute the newoperate.
Hopesomeone can give me somegoodrecommends!
0 Kudos
4 Replies
bicealyh
Beginner
158 Views
I have used below code add new task to the task queue. If I want to destroy all the tasks now, how can I do ?
MapRenderTask* renderTask = new( tbb::task::allocate_root() ) MapRenderTask(this->m_hWnd, m_threadContext);
tbb::task::enqueue(*readerTask);
ARCH_R_Intel
Employee
158 Views

I would be inclined to try a solution based on polling, like this:

Define a global atomc counter, say as "tbb::atomic G;". The counter value will be the current image generation that should be drawn. When starting to redraw:

  1. Get a fresh counter value by atomically incrementing the global counter. E.g. "unsigned g=++G;"
  2. Create the tasks, and give each task a copy of g.
  3. Each task, while running, occasionally reads G, and if it does not match its local g, quits and returns a partial result.

You could also consider using task_group_context objects and the form of task::allocate_root that takes a task_group_context argument. Then you can cancel all tasks related to that task_group_context. Though if the tasks might run for a long time, you will need to do polling anyway via task::is_cancelled(), and freeing the task_group_context object at the right time might be tricky. The counter solution avoids the freeing hassle.

With regard to the parallelization strategy, it may work well or it may run into problems because of the memory bandwidth expense of combining layers. An alternative would be to partition the image into sections and have a task per section.I don't know enough specifics about your situation to recommend which is best.

bicealyh
Beginner
158 Views
Thanks for your reply.
I also have one question aboutcounter solution like thatIf some heavytasks are running nowbutIwant to quicklydestroyall of the tasks, how can I do? In your counter solution way and at thestep 3, You mean that If I want to quickly return the task execute method,I should add the check G and g value function to all the heavy run function method?
Andrey_Marochko
New Contributor III
158 Views
Yes, I believe Arch meant something along these lines. Though of course you should not do the check too frequently. For example, if your heavy computational method consists of a loop doing 1000000 iterations, you should turn it into a nested loop with the outer loop doing 100 iterations and nested loop doing correspondingly 10000 iteration, and place the check in the outer loop. This way you'll get fast enough reaction to the cancellation signal, while avoiding overhead of too frequent checks.
Reply