- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello. I have a question about task sheduling. I have tasks who can lock some mutex to get exclusive access to some object(s) but how will that affect overall performance if i will have situation where i have task pool with 2 threads and task A running in thread 1 locks some mutex and then task B in thread 2 try to lock same mutex and fails. Is there a proper way to postpone that task(i guess i should run that task as child of this one). I know TBB task model is optimal only for calculations and not sure - should not be tasks "lock-free" as well? I use in my project ASIO for network IO(which is pretty slow and does not fit in TBB task_pool) and TBB only for things related o world calculations(physics, AI, network handlers i push from ASIO thread(s))
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Alexander,
TBB task scheduler is really aimed to calculation problems. The critical sections (mutexes and similar constructions) can be used inside tasks while they are relatively short. It is not recommended to perform IO operations inside TBB tasks (strictly speaking on TBB worker threads) because the number of threads in TBB thread pool is limited and blocking them can lead to overall performance degradation.
If you need IO operations in your application but want to use together with TBB, I would recommend you create a separate thread(s) for IO operations and utilize TBB task scheduler when calculations are needed. Perhaps, you may want to consider async_node in TBB flow graph API that can be used to organize synchronization between IO operations and TBB.
In addition, task and graph dependencies, continuation passing and other techniques can be used to avoid locking in some algorithms.
Regards, Alex
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I assume that TBB thread pool will be used only for AI/physics/other calculations, but IO handled by ASIO loop(files IO, network IO) but i am not pretty sure how it is possible to know which task depends on other task in process
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am not sure that I understand your question. Do you have dynamic dependencies between the tasks that are known only in runtime? Or do you need to run tasks when some particular event is occurred? Could you provide some details to better understand your needs, please?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry for bumping but i have different question - should not game engine probably do minimal synchronizations to avoid lock-contention? I looked at articles about game engine design and they tell same thing - you can either do stuff then select best result(discarding other results) or synchronize but with messaging and do that only in certain moments
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There are many techniques for optimization of synchronizations, e.g. different kind of mutexes, lock-free algorithms, task dependencies, continuation passing, asynchronous interfaces, specialized libraries and so on. Undoubtedly, it is better to avoid lock contention to improve overall performance. But it is quite difficult to recommend you something useful and specific without the details of your algorithm. Do you try to design client-server solution for a game? Do you have a computation problem with non trivial dependencies?
P.S. In my opinion, discussing game engine design is too broad on this forum and it is unlikely that you will find the game development professionals here (because this forum is devoted to Intel TBB related questions).
Regards, Alex
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page