both adding and forbidding behaviors, analysis tools such as model checkers, and architectures for large-scale applications.

In this article, we present the principles of behavioral programming and illustrate how to program behavioral applications in Java. We detail visual

Figure 1. a schematic view of the execution cycle of behavior threads using an enhanced publish/subscribe protocol.

behavioral programming with the LSC language and elaborate on how one deals with conflicting behaviors, underspecification, and a large number of simultaneous behaviors. We conclude with a comparison to other development approaches, applications, and future research.

 

behavior thread

Requested events behavior thread

Blocking
behavior
thread
behavior
thread

Selected event

1. All behavior threads synchronize and place their “bids”:

˲ Requesting an event: proposing that the event be considered for triggering, and asking to be notified when it is triggered;

˲ Waiting for an event: without proposing its triggering, asking to be notified when the event is triggered;

˲ Blocking an event: forbidding the triggering of the event, vetoing requests of other behavior threads.

2. An event that is requested and not blocked is selected;

3. The behavior threads that requested or wait for the selected event are notified;

4. The notified behavior vthreads progress to their next states, where they place new bids.

Figure 2. B-threads for increasing water flow.

Figure 2. B-threads for increasing water flow. the first two b-threads request the events add Hot and addCold three times, respectively. the third b-thread, Interleave, repeatedly waits for addHot while blocking addCold and vice versa, forcing alternation of these events. Without Interleave, the run would be three addHot followed by three addCold, due to b-thread priorities.

class AddHotThreeTimes extends BThread {
public void runBThread() {
for (int i = 1; i <= 3; i++) {
bp.bSync( addHot, none, none );
}
}
}

class AddColdThreeTimes extends BThread {
public void runBThread() {
for (int i = 1; i <= 3; i++) {
bp.bSync( addCold, none, none );
}
}
}

class Interleave extends BThread
public void runBThread() {
while (true) {
bp.bSync( none, addHot, addCold );
bp.bSync( none, addCold, addHot );
}
}
}

The first two b-threads
request add Hot and
addCold three times,
respectively. The third
b-thread, Interleave,
repeatedly waits for
addHot while blocking
addCold and vice versa,
forcing alternation of
these events. Without
Interleave, the run would
be three add Hot followed
by three addCold, due
to b-thread priorities. addHot
addCold
addHot
addCold
addHot
addCold
Event log of
the coordinated run

Basic Behavioral idioms

We propose the term behavioral application for software consisting of independent components (called b-threads) that generate a flow of events via an enhanced publish/subscribe protocol, as follows (see Figure 1). Each b-thread is a procedure that runs in parallel to the other b-threads. When a b-thread reaches a point that requires synchronization, it waits until all other b-threads reach synchronization points in their own flow. At synchronization points, each b-thread specifies three sets of events: requested events: the thread proposes that these be considered for triggering, and asks to be notified when any of them occurs; waited-for events: the thread does not request these, but asks to be notified when any of them is triggered; and blocked events: the thread currently forbids triggering any of these events.

When all b-threads are at a synchronization point, an event is chosen, that is requested by at least one b-thread and is not blocked by any b-thread. The selected event is then triggered by resuming all the b-threads that either requested it or are waiting for it. Each of these resumed b-threads then proceeds with its execution, all the way to its next synchronization point, where it again presents new sets of requested, waited-for and blocked events. The other b-threads remain at their last synchronization points, oblivious to the triggered event, until an event is selected that they have requested or are waiting for. When all b-threads are again at a synchronization point, the event selection process repeats. For a formal definition of this process see Harel et al. 25, 26

When more than one event is requested and not blocked, the semantics of event selection may vary. For example, the selection may be arbitrary or random, as in the default (a.k.a. naïve) semantics of the LSC Play-Engine; 21