On the client side, an engine runs in its own thread, and takes care of receiving and processing data objects from its corresponding manager on the server. A work engine, for example, would take care of getting work data from the work manager, executing the work, and requesting more work when it is done. Data objects are generally polymorphic, and know how to process themselves. Work data objects, for example, implement a doWork() method, which the work engine can call. Both the engine and the data have associated GUI objects which can be used for user interface. The engine and the GUIs are all contained in a chassis object, which can be an applet or application.
On the server side, an advocate object serves as the engine's representative, forwarding the engine's calls to the manager. The manager has access to several data pools, which may be shared by other managers serving other purposes. In Fig.1, for example, the work and result pools are shared by the work and watch managers, allowing the watch manager to watch the progress of the computation and inform watch engines of such things as new results and statistics. The whole set of associated managers and data pools compose a problem. A problem may include a program object, which creates and controls managers, and data pools, and fills the latter with data objects. The program may be active (i.e., have its own thread) or it may be passive, only reacting to occasional callbacks from its managers. For example, in our current applications, we implement a simple form of barrier synchronization by having the work manager do a callback when it finishes the current batch of work, and having the program object wait for such a callback before creating the next batch of work. A problem table keeps track of independent problems on the same server.
Writing an application using the Bayanihan framework typically involves first selecting and using generic components (shown as shaded boxes in Fig.1) from a library, and then defining application-specific components (shown as double-bordered boxes) by extending existing base classes. In this way, high-level application programmers can write a wide variety of applications with the same programming model (e.g., master-worker) by using a common set of pre-defined engine, manager, and data pool objects, and then defining different data, GUI, and program objects according to the application.
The framework also allows programmers and researchers to change generic objects in order to implement new functionality. Researchers, for example, can experiment with performance optimization by writing work manager objects with different scheduling algorithms. Similarly, replication-based fault-tolerance mechanisms can be implemented by extending the manager and data pool objects. Programmers can even implement entirely new parallel programming models by creating new sets of engines, managers, and data pools.
At present, we have implemented a generic set of engines and managers that support master-worker style programming with eager scheduling [2], and have used it for a variety of demo applications including factoring, Mandelbrot set rendering, and distributed web-crawling. We are currently working on extending the basic generic objects to implement performance, reliability, and programmability improvements. In the future, we also plan to implement generic components for supporting Cilk [3], and other adaptively parallel programming models.
