| Browsing |
| Home: | Java Fair Threads |
|---|---|
| Previous chapter: | Examples |
| Next chapter: | Conclusion |
| Links with Reactive Programming |
| Chapters |
1. Introduction 2. Threads 3. Fair Thread Framework 4. Java FairThreads API 5. Examples 6. Links with Reactive Programming 7. Conclusion
Until class of section Stopping Threads with Events, one
can see that there is no real need for using two distinct threads. Indeed, it
would be possible to merge the instructions of the controler with the
ones of the controlled method; in this way, the Until thread
would also test for the event presence, at fixed moments, say, just
before execution of the cooperate method. Thus, unnecessary
context switchings would be saved, which would leads to a more
efficient execution. Such a solution is of course more difficult to
program and less modular as the code of
the controlled method must be transformed.
Reactive Programming
The fair framework offers a way to conciliate efficiency and
programming ease through the use of reactive programs. Reactive
programs are basic elements of the Junior framework [10] which
is a set of Java classes for reactive programming. Junior programs are
usable through an API called Jr [9]. Comparison of threads and of
SugarCubes, a framework closely related to Junior, can be found in
[7]. The Web site [3] contains references to
reactive programming.
Reactive programming is based on the notion of an instant which is
shared by all concurrent components. Reactive programs are made of
basic instructions, with semantics defined in term of instants. For
example, the instruction Stop() of Junior stops execution for the
current instant, and execution at the next instant restarts in sequence
from it. Event based programming is possible in Junior; events are
instantaneously broadcast: an event generated during one instant is
received by all components waiting for it during the same instant.
Correspondance between fair threads and Junior is straigtforward: a
Junior instant corresponds to a fair scheduler phase, where all
threads are executed once; events have exactly the same semantics in
the two contexts; the cooperate() method of fair threads
corresponds to the Stop() instruction of Junior.
Junior programs can be used in the context of fair threads, by the
intermediate of class JrProgWrapper which extends
FairThread. For example, consider the class:
public class Kill extends Until
{
String msg;
public Kill(String s){ super("E"); msg = s; }
public void controled(FairScheduler scheduler){
for(int i = 0; i < 100; i++){
System.out.print(msg+"init ");
cooperate(5);
System.out.print(msg+"end ");
}
}
}
The equivalent class, made of a reactive program of type
Program, is the following:
public class Kill extends JrProgWrapper
{
Program prog =
Jr.Until("E",
Jr.Repeat(100,
Jr.Seq(Jr.Atom(new Print(msg+"init ")),
Jr.Seq(Jr.Repeat(5,Jr.Stop()),
Jr.Atom(new Print(msg+"end "))))));
public Kill(){ super(); setProgram(prog); }
}
Efficiency
Actually, instructions of concurrent programs in Junior are
interleaved (by the Par operator) during each instant, in a way
that allows broadcast of events. This approach is different from the
one of threads, as there is no need of context switching in Junior;
actually, context switches are replaced in reactive programming by
interleavings, as shown on Figure Merge.
Fig. 9: Merge of Reactive Instructions
Kill example of previous section. We consider
N threads and measure time T (in milliseconds) taken to run them (on a
MacIntosh G3, without printing). For N=100, one has T=6533ms. Now,
running the equivalent JrProgWrapper gives T= 1577ms. For
N=500, T=31189ms with FairThread, and T=3685ms with
JrProgWrapper.
Note that reactive programs consume less memory than threads; last
experiment, with N=500, needs 8.7MB with JrProgWrapper, and
79.3MB using threads. The overhead of memory used by threads is a
well-known problem; for example, with N=1000, it has not been possible
to run the previous example using threads, while no problem arise
using a reactive program.