59 | | |
60 | | --------------------------------------------------------------------------------------------------- |
61 | | == Boost.!Dataflow == |
| 59 | --------------------------------------------------------------------------------------------------- |
| 60 | == Boost.Coroutines == |
| 61 | * '''Author(s):''' Giovanni P. Deretta |
| 62 | * '''Version:''' |
| 63 | * '''State:''' |
| 64 | * '''Last upload:'''2008 Mars 05 |
| 65 | * '''Links:''' [https://svn.boost.org/svn/boost/sandbox/SOC/2006/corutines Boost Sandbox] [http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-coroutine.tar.gz&directory=Concurrent%20Programming& Boost Vault] |
| 66 | * '''Description:''' The Boost.Coroutine library contains a family of class templates that wrap function objects in coroutines. Coroutines are a generalization of subroutines that can return and be reentered more than once without causing the destruction of automatic objects. |
| 67 | Coroutines are useful whenever it is necessary to keep state across a function call, a job usually reserved to stateful function objects. |
| 68 | |
| 69 | --------------------------------------------------------------------------------------------------- |
| 70 | == Boost.Dataflow == |
66 | | * '''Links:''' [https://svn.boost.org/svn/boost/sandbox/dataflow-rewrite Boost Sandbox] |
67 | | * '''Description:''' |
| 75 | * '''Links:''' [http://dancinghacker.com/code/dataflow/ Documentation] [https://svn.boost.org/svn/boost/sandbox/dataflow-rewrite Boost Sandbox] |
| 76 | * '''Description:''' Dataflow is a generic library for dataflow programming. Dataflow programs can typically be expressed as a graph in which vertices represent components that process data, and edges represent the flow of data between the components. As such, dataflow programs can be easily reconfigured by changing the components and/or the connections. |
| 77 | |
| 78 | --------------------------------------------------------------------------------------------------- |
| 79 | == Boost.Egg == |
| 80 | * '''Author(s):''' Shunsuke Sogame |
| 81 | * '''State:''' |
| 82 | * '''Version:''' 0.91.0 |
| 83 | * '''Last upload:''' 30 Mars 2008 |
| 84 | * '''Links:''' [http://p-stade.sourceforge.net/boost/libs/egg/doc/html/index.html Documentation] |
| 85 | [https://p-stade.svn.sourceforge.net/svnroot/p-stade/trunk/boost SVN repository] [http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=egg.zip&directory=Function%20Objects& Boost Vault] |
| 86 | * '''Description:''' Egg is a header-only library for building Polymorphic Function Object which can be used with Boost.Lambda. Such a function object is called a Major Function Object. |
| 87 | Egg mainly provides three components: |
| 88 | * Function Builders which build Little Functions into Major Function Objects. |
| 89 | * Function Adaptors which take Polymorphic Function Objects then return adapted ones. |
| 90 | * Function Objects which are ports of famous function templates. |
| 110 | |
| 111 | --------------------------------------------------------------------------------------------------- |
| 112 | == Boost.Fiber == |
| 113 | * '''Author(s):''' Oliver Kowalke |
| 114 | * '''Version:''' |
| 115 | * '''State:''' |
| 116 | * '''Last upload:'''2008 Oct 30 |
| 117 | * '''Links:''' [http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-fiber.v2.tar.gz&directory=Concurrent%20Programming& Boost Vault] |
| 118 | * '''Description:''' Boost.Fiber implements lightweight threads of execution - so called fibers |
| 119 | |
| 120 | --------------------------------------------------------------------------------------------------- |
| 121 | == Boost.Fsm == |
| 122 | * '''Author(s):''' Andrey Semashev |
| 123 | * '''State:''' |
| 124 | * '''Version:''' |
| 125 | * '''Last upload:''' |
| 126 | * '''Links:''' [http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip&directory=& Boost Vault] |
| 127 | * '''Description:'''The Boost.FSM library is an implementation of FSM (stands for Finite State Machine) programming concept. |
| 128 | There are many cases when a developer would like to distinguish behaviour of a given object depending on some conditions or its internal state. For example, while developing software to control an charging turnstile a programmer would like to separate states in which the turnstile may persist: an idle state, when the device awaits for another passenger that would like to pass; a processing state, when the passenger have come and put his ticket into the device; and the passing state, when the turnstile lets the passenger pass through. In fact, each state describes a different reaction of the machine at the same events. That's why a passenger may only pass after paying for ticket. Obviously, the turnstile have to be able to change its internal state in order to function properly, this is called state switching or transitions between states (or just transitions for short). |
| 129 | This implementation is aimed to ease the creation of such state machines in C++. It supports constructing passive automatons (which means that every action the machine performs is a response to some external event) with finite number of states and finite number of transitions (that is why they are called finite state machines). The main goals of the library are: |
| 130 | * Simplicity. It should be very simple to create state machines using this library. |
| 131 | * Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases. |
| 132 | * Extensibility. A developer may want to add more states to the existing state machine, for example, the maintenance state for the turnstile mentioned above, and this addition should be relatively safe since it shouldn't interfere with the existing states. The developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code. |
97 | | * thread specific shared pointer: this is an extension of the thread_specific_ptr providing access to this thread specific context from other threads. As it is shared the stored pointer is a shared_ptr instead of a raw one. |
98 | | * thread keep alive mechanism: this mechanism allows to detect threads that do not prove that they are alive by calling to the keep_alive_point regularly. When a thread is declared dead a user provided function is called, which by default will abort the program. |
99 | | * thread tuple: defines a thread group where the number of threads is know statically and the threads are created at construction time. |
100 | | * set_once: a synchronizer that allows to set a variable only once, notifying to the variable value to whatever is waiting for that. |
101 | | * thread_tuple_once: an extension of the boost::thread_tuple which allows to join the thread finishing the first, using for that the set_once synchronizer. |
102 | | * thread_group_once: an extension of the boost::thread_group which allows to join the thread finishing the first, using for that the set_once synchronizer. |
| 143 | * thread specific shared pointer: this is an extension of the thread_specific_ptr providing access to this thread specific context from other threads. As it is shared the stored pointer is a shared_ptr instead of a raw one. |
| 144 | * thread keep alive mechanism: this mechanism allows to detect threads that do not prove that they are alive by calling to the keep_alive_point regularly. When a thread is declared dead a user provided function is called, which by default will abort the program. |
| 145 | * thread tuple: defines a thread group where the number of threads is know statically and the threads are created at construction time. |
| 146 | * set_once: a synchronizer that allows to set a variable only once, notifying to the variable value to whatever is waiting for that. |
| 147 | * thread_tuple_once: an extension of the boost::thread_tuple which allows to join the thread finishing the first, using for that the set_once synchronizer. |
| 148 | * thread_group_once: an extension of the boost::thread_group which allows to join the thread finishing the first, using for that the set_once synchronizer. |
| 191 | |
| 192 | --------------------------------------------------------------------------------------------------- |
| 193 | == Boost.Poet == |
| 194 | * '''Author(s):''' Frank Mori Hess |
| 195 | * '''Version:''' |
| 196 | * '''State:''' |
| 197 | * '''Last upload:''' |
| 198 | * '''Links:''' [http://www.comedi.org/projects/libpoet/index.html Home Page] |
| 199 | * '''Description:''' libpoet is a C++ parallel programing library. It provides support for easily creating active objects, creating monitor objects, and automatically validating mutex locking order. |
| 200 | |
| 201 | Active objects provide concurrency and thread-safety, since each active object executes in its own thread. Futures are employed to communicate with active objects in a thread-safe manner. To learn more about the active object concept, see the paper "Active Object, An Object Behavioral Pattern for Concurrent Programming." by R. Greg Lavender and Douglas C. Schmidt. Some of the more important active object classes in libpoet are poet::active_function, poet::future, and poet::scheduler. |
| 202 | |
| 203 | Monitor objects provide thread-safety via automatically locked access to an object. See the paper "Monitor Object, An Object Behavioral Pattern for Concurrent Programming" by Douglas C. Schmidt for more information about monitor objects. The poet::monitor_ptr, poet::monitor, and poet::monitor_base classes in libpoet provide support for monitor objects. |
| 204 | |
| 205 | Finally, the poet::acyclic_mutex class provides a wrapper for mutex classes which adds automatic validation of a program's mutex locking order. Following a consistent locking order ensures your program will not deadlock due to problems such as "deadly embrace" or the "dining philosophers" problem. |
| 206 | |