- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello.
I a heavy access in reading from some maps, because i use a system of catalogs, and every catalog (mesh, lights, animation, shaders) has a map where to go and pull out a smart pointer for objects that are rendered cyclically.
Access to the maps after they have been filled (in the initialization phase) is read only, does not add any data, only read.
Here, too, i'm in read-only and I'm not have to worry about the problems of multithreading?
In this case it is useful to use the tbb containers ?
thanks.
I a heavy access in reading from some maps, because i use a system of catalogs, and every catalog (mesh, lights, animation, shaders) has a map where to go and pull out a smart pointer for objects that are rendered cyclically.
Access to the maps after they have been filled (in the initialization phase) is read only, does not add any data, only read.
Here, too, i'm in read-only and I'm not have to worry about the problems of multithreading?
In this case it is useful to use the tbb containers ?
thanks.
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
> Here, too, i'm in read-only and I'm not have to worry about the problems of multithreading?
Not necassary. Physically read-only accesses are safe, but what you have are logically read-only accesses. What lookup() does internally? Who knows. It perfectly can do some internal caching and/or statistics and/or whatever.
However in most cases logically read-only accesses to containers are physically read-only, because of exactly the scenario you described. You just need to be sure.
> In this case it is useful to use the tbb containers ?
They are not only useless, they may have considerable negative impact on scalability/performance. What you need is "almost" single-threaded containers (specifically crafted for concurrent const accesses). Most sane implementations of C++ standard library containers provide such guarantees. That's usually called "basic thread safety" or "as safe as int".
Not necassary. Physically read-only accesses are safe, but what you have are logically read-only accesses. What lookup() does internally? Who knows. It perfectly can do some internal caching and/or statistics and/or whatever.
However in most cases logically read-only accesses to containers are physically read-only, because of exactly the scenario you described. You just need to be sure.
> In this case it is useful to use the tbb containers ?
They are not only useless, they may have considerable negative impact on scalability/performance. What you need is "almost" single-threaded containers (specifically crafted for concurrent const accesses). Most sane implementations of C++ standard library containers provide such guarantees. That's usually called "basic thread safety" or "as safe as int".
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page