What was the rationale behind making AssetLocators thread-local? Wouldn’t it be better to have some kind of synchronization around setRootPath (to protect initialization from being called from multiple threads at same time) and after that just use single instance?
I’m asking, because my locators are quite heavy to set up (preload entire catalogue of files), but after that can serve things reasonably fast and thread-safe. From what I have seen, all provided locators are thread-safe for retrieving assets (only setRootPath could cause problems if called from multiple threads at same time). I’m now working on AssetServer (which will serve data from AssetManager over the http) and current setup is extremly costly for multi-threaded web server to work with.
Yes, sharing static instance works… except I need multiple locators of same type with different root paths. So it would turn into having a static map of rootpath to real locator - not hard, but just extra work. Wanted to find out if there is a real reason behind that or it just happened to be that by accident.
@abies said:
Yes, sharing static instance works... except I need multiple locators of same type with different root paths. So it would turn into having a static map of rootpath to real locator - not hard, but just extra work. Wanted to find out if there is a real reason behind that or it just happened to be that by accident.
All other locators are low cost to create, so its a valid option for multithreading.
Why dont you make your catalogue a singleton / similar and share it between different assetlocators. I guess there is no real need that you share your cataloge or?
Eg static public Catalog? CatalogCache.get(rootpath);
What I don’t understand is why we need per-thread locator to achieve thread safety. From what I have seen, all locator locate(…) methods are thread-safe even if same instance is called from multiple threads at very same time. Is it only about initialization-time thread safety (setRootPath)?
Regarding the workaround in my case - yes, I understand what can be done.
@abies said:
What I don't understand is why we need per-thread locator to achieve thread safety. From what I have seen, all locator locate(..) methods are thread-safe even if same instance is called from multiple threads at very same time. Is it only about initialization-time thread safety (setRootPath)?
Regarding the workaround in my case - yes, I understand what can be done.
We need per-thread loaders and they need locators.
@Empire Phoenix said:
Actually since the interface does not state that they must have a thread save internal logic, this might break tons of other persons locators.
No, its the other way round. Because the locators are instantiated threadlocal they don’t need to have special thread safety built in.
If you write a locator that accesses system-wide singletons and use it from multiple threads… Well then you didn’t think it through and couldn’t solve that at the locator stage anyway. Making the assetmanager “threadsafe” using synchronized and locks would rather make it deadlock-prone
@normen said:
No, its the other way round. Because the locators are instantiated threadlocal they don't need to have special thread safety built in.
If you write a locator that accesses system-wide singletons and use it from multiple threads… Well then you didn’t think it through and couldn’t solve that at the locator stage anyway. Making the assetmanager “threadsafe” using synchronized and locks would rather make it deadlock-prone
That’s what empire was saying. If we “fixed” this then we’d potentially break people counting on the current level of thread safety. Or as you’ve pointed out: worse.
@pspeed said:
That's what empire was saying. If we "fixed" this then we'd potentially break people counting on the current level of thread safety. Or as you've pointed out: worse.
