That all makes total sense Larry - thanks for clearing that up :) We now create a single (global) cache and use that across the threads. Not sure why I thought we had to create a (shared) cache for each thread!
Best Regards, Simon > On 8 Dec 2014, at 20:47, Larry Gritz <[email protected]> wrote: > > Ah, I think I understand. > > The idea of multiple calls to TextureSystem::create (or the underlying > ImageCache::create) was that multiple plugins, libraries, or components > within an app may each need a TextureSystem, but you don't want multiple > underlying image caches live, and the component have a hard time coordinating > among them or even be unaware whether there are other components sharing the > cache, so TS::create is able to dole out multiple TS's with a single shared > cache. > > We never assumed that individual threads, constantly being created and > destroyed, would be requesting TS::create every time they start up. It's not > meant to handle that usage case, because you're not supposed to want a > different TextureSystem for each thread. There's a difference between sharing > one texture system, versus everybody getting a their own texture system which > all reference the same underlying ImageCache. See? > > I think the right thing to do is to request the texture cache handle just > once for the app, store it in a global variable, and have your threads all > just use that pointer when they are created. > > I suppose another option would be to have a global OIIO option that controls > whether an invalidate_all() call is made upon a create() that returns the > shared cache. But, that approach would still wastefully do an > allocation/construction of a TextureSystem every time you spawn a thread, > which is unnecessary. > > -- lg > > > On Dec 8, 2014, at 11:56 AM, Simon Smith <[email protected] > <mailto:[email protected]>> wrote: > >> Hi, >> >> I have a question about shared texture caches. >> Basically, are these a “Good Thing” to use across threads? >> If not, how “bad” is it? >> >> We have a system whereby threads are created for jobs whenever they are >> needed (it actually uses Qt’s Concurrent system). >> Each thread can use the texture system, so I had it set to share the texture >> cache across threads. >> >> This is fine until you have a file that does not exist. >> >> One thread will come along, try to open the file, fail, and mark it as >> broken (this is all done when inside the get_texture_handle) which is >> correct. >> Now, this thread is going to call texture() in a little while, but in the >> meantime another thread is fired up as part of the job. >> >> When this gets initialised, we create a new texture cache member pointer by >> calling TextureSystem::create() >> Inside here, because it’s marked as being shared, it will invalidate all >> files in the cache. >> Part of this invalidation means the broken flag is reset to false. >> >> Now the other thread gets a look in, tries to use the file in the texture >> call, and crashes because the broken flag is reset and it goes sailing >> through and tries to access the 0th element in the subimage list (which >> obviously does not exist!) >> >> So, I’m wondering how I should best handle this situation. >> Should I perhaps: >> a) Not use a shared texture cach (this sounds like a bad thing to me) >> b) Not create new texture cache pointers but to share the one globally over >> threads - but how would I get the PerThreadInfo instances that I need? >> c) Something else …. >> >> Any thoughts or help on this would be greatly appreciated - I’m sure this >> must be a very common scenario! >> >> Best Regards, >> Simon >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
