Trying to use atomic
How can I buildthese librariesas a static library?
There are no static libraries by design. Most libraries cause no problems if staticly loaded multiple times. But some libraries manage critical resourcesand need to implement asingleton object to keep absolute control. It would not do to have several staticly linked TBB libs, each with their own thread pool, all competing for the hardware threads, bogging the system down. Implementing singleton objects is much easier and more foolproof using shared objects, thus no static lib.
Your reply certainly is understandable. HOwever,as soon as I begin to think about more than one TBB israises, to me, perhaps the most significant questions I have about the TBB tasks model. The notion of a single thread pool assumes that no threadswould be running outside of TBB.How do we manage threads that are external to the TBB elements so that theybehave appropriately? (e.g. typically we desire the capacity to either pre-empt or yield to the TBB managed application.)
As far as I have determined, TBB provides no means to manage thread priorities. Granted, there is some sound logic for this, since the entire domain of thread management is abstracted by design into"tasks". However, we typically find ourselveswith complex systems which may require, at the very least, positioning a TBB application within a range of thread priorities that neither preempt some high level event manager nor yield to somenon-realtime backgroundprocess such as a UI feedback or a telnet service daemonfor status monitoring.
Or, in a more challenging case (in addition to the above) suppose I want to run a pipeline, held to some real-time frame rate, andsomesecond pipelinecan utilize what is left in a non-deterministic fashion.
It would certainly be useful to have the capacity to assign TBB tasks to a priority range. Is there any effort being made on this currently?
Intel Threading Building Blocks was constructed to "play well with others" in a complex threaded landscape. We have deployed it into commercial applications that are already partially threaded, and for the most part it seems to behave well. There have been situations, though, where oversubscription has occurred because unregistered extra threads (such as from an OpenMP pool) cause the creation of multiple task_scheduler_init objects. Generally when these mixed threading environments workbest is when the pools are not active at the same time. This often happens quite naturally as threaded code is associated with one distinct part of an application or another.
I know that thread priority is a concern of the development team. I can't say for certain when features supporting priorities will be available. Stay tuned to the TBB Blogospherefor announcements of future releases and planned feature enhancements.