Programming languages: Adding parallel and persistent sets to modula-3
Implementation
The basic idea is to keep most part of the implementation outside the compiler. The same idea has been applied in the SRC-Modula-3 compiler [Nels] in connection with Threads. The compiler does the necessary type checks and makes some preparations for optimizing the set operations. The actual implementation is given in form of user modules. The interface of this module is the same for any kind of implementation. The compiler generates calls on this « standardized » interface. The advantage of this approach is its flexibility: alternative resp.
experimental implementations can be given. It fits well for a source-to-source compiler. Two implementations are actually in work: cheap sets and PPOST.
Cheap sets
Cheap sets uses a simple hash table with chaining on collision. The size of the table is determined by the hint given by the application (a default is taken, if no such hint is given, see listing 4). Classes and views are also implemented on top of sets (listings 5 and 6). This implementation is entirely sufficient for non-persistent sets.
Persistent cheap sets are simply loaded at program start (if already available) and stored at completion. Persistent sets are not updated if the program crashes. Parallelism is mapped on standard Modula-3 threads.
PPOST
PPOST is a memory-resident parallel object store [Bösz], which stores sets or classes of objects in the main memory of a number of processors. It fits very well for implementing parallel and persistent sets and classes.
The Architecture of PPOST
PPOST’s main components are (figure 1): « object store » (consisting of a number of object storage machines), « log machine », « checkpoint machine », « archive machine » and « users » (consisting of a number of user machines). All the data of the stored objects (i.e. their attributes and methods) lie in the memory of the storage machines. Every transaction that reads or changes the data is executed on those machines. Transactions are initiated by the user machines and processed by the object store. Changes of the data in the object store are reported to the log machine which saves the information onto a logfile in nonvolatile memory.
The checkpoint machine reads the log produced by the log machine and saves all commited changes to the disc-based database. Only the checkpoint and the log machine are involved in producing the disc image. The user transaction can go on as soon as the information about the changes is transmitted to the log machine.
The archive machine saves the disc-database to a secondary storage, like a magnetic tape.
This is considered as a normal activity of the data-store and again is done in background without interrupting the user-transactions.
We call this pipeline-like way to decouple user-transactions from issues of persistence « vertical parallelism ».
Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)Programming languages adding parallel and persistent sets to modula-3 (84,0 KO) (Cours PDF)
