Logo Search packages:      
Sourcecode: scala version File versions  Download package

scala::actors::FJTask Class Reference

Inheritance diagram for scala::actors::FJTask:

scala::actors::FJTask::Par scala::actors::FJTask::Par2 scala::actors::FJTask::Seq scala::actors::FJTask::Seq2 scala::actors::FJTask::Wrap scala::actors::FJTaskRunnerGroup::InvokableFJTask

List of all members.

Detailed Description

Abstract base class for Fork/Join Tasks.

FJTasks are lightweight, stripped-down analogs of Threads. Many FJTasks share the same pool of Java threads. This is supported by the FJTaskRunnerGroup and FJTaskRunner classes, that mainly contain methods called only internally by FJTasks. FJTasks support versions of the most common methods found in class Thread, including start(), yield() and join(). However, they don't support priorities, ThreadGroups or other bookkeeping or control methods of class Thread.

FJTasks should normally be defined by subclassing and adding a run() method. Alternatively, static inner class Wrap(Runnable r) can be used to wrap an existing Runnable object in a FJTask.

FJTaskRunnerGroup.execute(FJTask) can be used to initiate a FJTask from a non-FJTask thread. And FJTaskRunnerGroup.invoke(FJTask) can be used to initiate a FJTask and then wait for it to complete before returning. These are the only entry-points from normal threads to FJTasks. Most FJTask methods themselves may only be called from within running FJTasks. They throw ClassCastExceptions if they are not, reflecting the fact that these methods can only be executed using FJTaskRunner threads, not generic java.lang.Threads.

There are three different ways to run a FJTask, with different scheduling semantics:

The main economies of FJTasks stem from the fact that FJTasks do not support blocking operations of any kind. FJTasks should just run to completion without issuing waits or performing blocking IO. There are several styles for creating the run methods that execute as tasks, including event-style methods, and pure computational methods. Generally, the best kinds of FJTasks are those that in turn generate other FJTasks.

There is nothing actually preventing you from blocking within a FJTask, and very short waits/blocks are completely well behaved. But FJTasks are not designed to support arbitrary synchronization since there is no way to suspend and resume individual tasks once they have begun executing. FJTasks should also be finite in duration -- they should not contain infinite loops. FJTasks that might need to perform a blocking action, or hold locks for extended periods, or loop forever can instead create normal java Thread objects that will do so. FJTasks are just not designed to support these things. FJTasks may however yield() control to allow their FJTaskRunner threads to run other tasks, and may wait for other dependent tasks via join(). These are the only coordination mechanisms supported by FJTasks.

FJTasks, and the FJTaskRunners that execute them are not intrinsically robust with respect to exceptions. A FJTask that aborts via an exception does not automatically have its completion flag (isDone) set. As with ordinary Threads, an uncaught exception will normally cause its FJTaskRunner thread to die, which in turn may sometimes cause other computations being performed to hang or abort. You can of course do better by trapping exceptions inside the run methods of FJTasks.

The overhead differences between FJTasks and Threads are substantial, especially when using fork() or coInvoke(). FJTasks can be two or three orders of magnitude faster than Threads, at least when run on JVMs with high-performance garbage collection (every FJTask quickly becomes garbage) and good native thread support.

Given these overhead savings, you might be tempted to use FJTasks for everything you would use a normal Thread to do. Don't. Java Threads remain better for general purpose thread-based programming. Remember that FJTasks cannot be used for designs involving arbitrary blocking synchronization or I/O. Extending FJTasks to support such capabilities would amount to re-inventing the Thread class, and would make them less optimal in the contexts that they were designed for.

[Introduction to this package. ]

See also:


Definition at line 133 of file FJTask.java.

Public Member Functions

void cancel ()
void fork ()
final boolean isDone ()
void join ()
void reset ()
void start ()

Static Public Member Functions

static void coInvoke (FJTask[] tasks)
static void coInvoke (FJTask task1, FJTask task2)
static FJTaskRunner getFJTaskRunner ()
static IFJTaskRunnerGroup getFJTaskRunnerGroup ()
static void invoke (FJTask t)
static FJTask par (FJTask task1, FJTask task2)
static FJTask par (FJTask[] tasks)
static FJTask seq (FJTask task1, FJTask task2)
static FJTask seq (FJTask[] tasks)
static void yield ()

Protected Member Functions

final void setDone ()

Private Attributes

volatile boolean done


class  Par
class  Par2
class  Seq
class  Seq2
class  Wrap

The documentation for this class was generated from the following file:

Generated by  Doxygen 1.6.0   Back to index