4 ms·
You can have your cake and eat it too -- there's no throwing away of performance gains. Libraries can use threads, but not directly or "silently". They should
by chubot 10y ago
You can have your cake and eat it too -- there's no throwing away of performance gains. Libraries can use threads, but not directly or "silently". They should take threads as parameters. Then the application knows when they're being used and the application programmer can reason about it.
- amelius 10y agoYes, in theory. In practice, every library developer/maintainer uses different guidelines.
- hughperkins 10y agoIn practice, a lot of library developers/maintainers read this list, or know someone who does.
- gpderetta 10y agocompilers and runtimes can spawn threads implicitly when required (think of openmp, cilk+, or even autopar). Are you saying that libraries shouldn't use these facilities?
- lmm 10y agoIf you're spawning threads implicitly then you're no longer a library, you're a framework. Sometimes a framework is a good fit, but frameworks don't compose (if you try to use two frameworks in the same application you're gonna have a bad time) so there is a cost. But in any case, better a framework that's explicitly a framework than a "library" which can't actually be used freely in general-purpose code.
- gpderetta 10y agowould you consider a parallelized BLAS a framework?
- 2trill2spill 10y ago> If you're spawning threads implicitly then you're no longer a library, you're a framework. That't not what makes a framework. It's all about inversion of control, you call a library and a framework calls you. http://stackoverflow.com/questions/3057526/framework-vs-toolkit-vs-library http://stackoverflow.com/questions/3057526/framework-vs-tool...
- lmm 10y agoIf it's spawning threads, it's controlling the control flow. Either it's calling you, or the control flow is out of control.
- gnaritas 10y agoNo. His definition is correct. If you make the call, it's a library, that it might use threads during that call does not make it a framework. Libraries don't mean you're in full control of everything, they only mean you invoke all interactions and get results back rather than you subclass something and plug a part into a framework. If you have to subclass something, it's a framework.
- chubot 10y agoI've used OpenMP a little bit, and I would probably avoid it for libraries. I might use it to start out an application, since it requires very little code for dumb parallelism. But if I were making a real library, I would try to abstract the concurrency policy away so the user can control it. This should be trivial by layering the library. Just provide a bunch of single-threaded functions, and then some OpenMP wrappers. Then user can call the single-threaded functions if she wants to do something different. What I don't want is OpenMP baked deeply into the program logic. I think it shares the problem I was talking about. If you have 10 different libraries using OpenMP in an app, and the app is ITSELF multi-threaded, it seems like you have a mess of threads that you have no control over.