Skip to main content

Table 1 The structure of the tuples in GridTS

From: Towards an opportunistic grid scheduling infrastructure based on tuple spaces

\(\langle\mathit{\mbox{``}TICKET\mbox{''}, ticket} \rangle\)—represents the tickets used to enforce an order on task execution. The objective is to guarantee the fairness of the scheduling, i.e., starvation freedom. The ticket field contains the ticket number. The tuple space is initialized with a tuple \(\langle\mathit{\mbox{``}TICKET\mbox{''}, 0}\rangle\).

\({\langle\mathit{\mbox{``}JOB\mbox{''}, jobId, numberTasks, ticket,information, code}\rangle}\)—represents all common information of tasks from the same job. The nTasks field contains the number of tasks that compose the job, ticket is the ticket value associated with the job, and information indicates the attributes for job execution (e.g., the required processor speed, memory, operating system). The field code can contain either the code to be executed or a reference to its location (e.g., an URL).

\(\langle\mathit{\mbox{``}TASK\mbox{''}, jobId, taskId, information,parameters}\rangle\)—represents the task to be executed. The information field has attributes for task execution. The parameters field contains input data for the task or a reference to its location. A task is uniquely identified by jobId and taskId.

\({\langle\mathit{\mbox{``}RESULT\mbox{''}, jobId, taskId, result}\rangle}\)—represents the result of a task execution. The result field contains the result or a reference to its location.

\({\langle\mathit{\mbox{``}CHECKPOINT\mbox{''}, jobId, taskId, checkpoint}\rangle }\)—represents the state of a task after a partial execution, i.e., a checkpoint. If a resource fails during the execution of a task, this checkpoint is used by another resource to continue executing the task. The checkpoint field contains the partial state of task computation or a reference.

\({\langle\mathit{\mbox{``}TRANS\mbox{''}, transId, ticket, jobId}\rangle}\)—indicates the last transaction executed by a broker, since brokers execute a sequence of two transactions. The objective is to prevent the broker from re-executing the same transaction if it fails and recovers. transId identifies the last process transaction successfully committed. ticket and jobId have the usual meanings and are used to specify what the broker was doing when it failed.