Gestión del Conocimiento y productividad

7.1.1.1 Library Routines

Because the IOT service is intended as an extension to Unix file systems, there are two basic alternatives to presenting its programming interface: using new system calls implemented in the kernel or library routines at user level. We choose the latter for the following two reasons. First, placing the IOT programming interface at system level runs against the long- held tradition of keeping the system call interface intact while enhancing operating system services for various purposes. Second, a library interface is more convenient to implement and port to other platforms. Although the current interface is provided only in the C programming language, it can be extended to other programming languages straightforwardly if needed.

The IOT programming interface contains two basic routines indicating the beginning and the end of a transaction. Because of the need to specify a conflict resolution option, they are not mere syntactic tokens and carry crucial information from the application to the transaction system. The definition of the two routines is shown in Figure 7.1 and their usage and functionality are described below.

typedef struct f char opt, char *asr g iot spec;

typedef struct f char **argv, char **env,

char *pwd, int umask

g iot env;

int begin iot(iot spec *, iot env *);

int end iot(int, iot spec *);

Figure 7.1: Library Routines for Programming Transactions

The begin iot routine is used to start a new transaction. Its return value is either a positive integer which represents the identifier of the newly created transaction or a negative integer which records an IOT-defined error code. The first argument specifies the conflict resolution requirement of the transaction. Theopt component uses pre-defined constants to select the resolution option, and the asr component supplies the pathname of the resolver executable file if the selected option is ASR. The second argument provides the environment information necessary for automatic conflict resolution. The argv component is a list of strings containing the pathname of the transaction application executable file and the command line arguments. The envcomponent is a list of strings representing the environment variable definitions. The pwd component records the pathname of the working directory where the transaction execution is started.

Theend iotroutine is used to terminate a currently running transaction. A return value of zero means that the call succeeded. Otherwise it contains an IOT-defined error code. The first argument is the identifier of the transaction to be terminated, while the second argument is the same as the first argument of thebegin iotroutine. Theoretically,iot endis a better place than begin iotto specify the resolution option because the application has already known what happened during the transaction execution whenend iotis called. However, from the reliability point of view, begin iot is a more appropriate choice because the transaction execution may encounter abnormal situations and exit before the correspondingend iotever gets called. As a compromise, we allow resolution requirement to be specified in both routines.

7.1.1.2 Programming A Transaction

Well Structured Code Adaptation The programming of a transaction is straightforward by simply using the two routines to wrap up the code segment whose execution needs to be treated as a transaction. When the source code of the target application is available, the additional transaction code only needs to make up the resolution requirement specification, obtain the

necessary environment information and put a pair of begin iot andend iot calls at the appropriate locations, as shown in Figure 7.2. Even if the source code of the target application is not available, it is still possible to put the transaction wrappers around it as shown in Figure 7.3.

#include "iot.h"

/* other decls. */

extern char **environ;

main(char **argv, int argc) f

iot spec spec = f ASR, "/coda/misc/bin/resolver" g;

iot env env;

char pwd[MAXPATHLEN]; int tid;

/* other definitions */ getwd(pwd);

env.argv = argv; env.env = environ; env.pwd = pwd; env.umask = umask(0); umask(env.umask);

tid = begin iot(&spec, &env); /* main body */

(void) end iot(tid, &spec);

g

/* the rest of the program */

This is a template that shows the overall structure of a transaction program. ASRis a pre-defined constant used to indicate the corresponding conflict resolution option. The error handling for the IOT interface calls is intentionally left out for clarity.

Figure 7.2: A Template Transaction Program Using Target Application Source Code

Transactional Application Development The development of a transactional application is rather simple. The IOT system provides a standard header file iot.h that contains all the necessary declarations and definitions for using the two IOT interface routines. The transaction program only needs to includeiot.hand link with the provided IOT library filelibiot.a.

Transaction Scope Limitation In principle, a transaction should be able to cover any segment of a program and obtain the standard IOT properties for the execution of that segment. In the current implementation, it is only suitable to bracket the entire application, i.e., the wholemain

function of the program, as a single transaction. The main reason is that when the transaction needs to be OCC re-executed, the transaction system is only capable of re-executing the entire application instead of the selected segment. Note that this restriction is more the consequence of the transaction system’s lack of run-time transaction execution knowledge rather than the design decision of using OCC as the concurrency control algorithm. If the transaction system were fully integrated with the application run-time system, it would be possible to provide the ability to re-execute any segment of a program.

#include "iot.h" extern char *environ;

main(char **argv, int argc) f

iot spec spec = f MANUAL, (char *)0 g;

iot env env;

char pwd[MAXPATHLEN], cmd[1024]; int tid, i;

getwd(pwd);

env.argv = argv; env.env = environ; env.pwd = pwd; env.umask = 0;

tid = begin iot(&spec, &env);

sprintf(cmd, "/usr/misc/bin/latex");

for (i = 1; i < argc; i++)

sprintf(cmd + strlen(cmd), " %s", argv[i]); system(cmd);

(void)end iot(tid, &spec);

g

This program can executelatexas a transaction using the manual conflict resolution option, as indicated by the pre-defined constantMANUAL. Thesystemcall will create ashsub-process to execute the assembledlatexcommand. The error handling for the IOT interface calls is left out for clarity.