The Synchronous Blog

A blog about reactive programming languages.

Posts Tagged ‘reactivity

Dynamic Applications in Céu (1/2)

with 4 comments

The basic prerequisite to build dynamic applications is language support to deal with abstractions and code reuse. Programming languages provide a multitude of abstraction mechanisms, from simple abstract data types, to OO classes. Regarding an abstraction, an effective mechanism should provide means to deal with at least the following points:

  • Hide its internal implementation details.
  • Expose a uniform programming interface to manipulate it.
  • Control its life cycle.

As an example, to build an ADT in C, one can define a struct, hide it with a typedef, expose functions to manipulate it, and control instances with local variables or malloc/free. Classes extend ADTs with richer mechanisms such as inheritance and polymorphism. Furthermore, the life cycle of an object is typically controlled automatically through a garbage collector.

Céu organisms

Abstractions in Céu are created through organisms, which basically reconcile threads and objects into a single concept:

  • An organism has intrinsic execution, being able to react to the environment on its own.
  • An organism exposes properties and actions in order to interact with other organisms during its life cycle.

Like an object, an organism exposes properties and methods (events in Céu) that can be accessed and invoked (emitted in Céu) by other instances. Like a thread, an organism has its own line(s) of execution, with persistent local variables and execution state.
In contrast, an object method call typically shares the same execution context with its calling method. Likewise, a thread does not expose fields or methods.

An example

The program below defines the class HelloWorld and executes two instances of it:

  class HelloWorld with
     var int id;   // organism interface
  do               // organism body
     every 1s do
         _printf("[%d] Hello world!\n",
                  this.id);
     end
  end

  var HelloWorld hello1, hello2;
  hello1.id = 1;
  hello2.id = 2;
  await FOREVER;
.

The behavior can be visualized in the video on the right. The top-level code creates two instances of the class HelloWorld, initializes the exposed id fields, and then awaits forever. As organisms have “life”, the two instances react to the environment autonomously, printing the “Hello world!” message every second.

Note in the example that organisms are simply declared as normal variables, which are automatically spawned by the language runtime to execute in parallel with its enclosing block.

In the following variation, we add the event stop in the class interface and include another line of execution in the organism body:

  class HelloWorld with
     var   int  id;
     event void stop;
  do
     par/or do
         every 1s do
             _printf("[%d] Hello world!\n",
                      this.id);
         end
     with
         await this.stop;
     end
  end

  var HelloWorld hello1, hello2;
  hello1.id = 1;
  hello2.id = 2;

  await 3s500ms;
  emit hello1.stop;
  hello2.id = 5;
  await 2s;
  emit hello2.stop;

  await FOREVER;
.

Now, besides printing the message every second, each organism also waits for the event stop in parallel. The par/or construct splits the running line of execution in two, rejoining when any of them terminate. (Céu also provides the par/and construct.)

After the top-level code instantiates the two organisms, it waits 3s500ms before taking the actions in sequence. At this point, the program has 5 active lines of execution: 1 in the top-level and 2 for each of the instances. Each organism prints its message 3 times before the top-level awakes from 3s500ms.

Then, the top-level emits the stop event to the first organism, which awakes and terminates. It also changes the id of the second organism and waits more 2s. During this period the second organism prints its message 2 times more (now with the id 5).

Note that although the first organism terminated its body, its reference hello1 is still visible. This way, the organism is still alive and its fields can be accessed normally (but now resembling a “dead” C struct).

Execution model

Lines of execution in Céu are known as trails and differ from threads in the very fundamental characteristic of how they are scheduled.

Céu is a synchronous language based on Esterel, in which lines of execution advance together with a unique global notion of time.
In practical terms, this means that Céu can provide seamless lock-free shared-memory concurrency. It also means that programs are deterministic and have reproducible execution. As a tradeoff, concurrency in Céu is not suitable for algorithmic-intensive activities as there is no automatic preemption among trails.

In contrast, asynchronous models have time independence among lines of execution, but either require synchronization primitives to acquire shared resources (e.g. locks and semaphores in pthreads), or completely forbid shared access in favor of message passing (e.g processes and channels in actor-based languages). In both cases, ensuring deterministic execution requires considerable programming efforts.

The post entitled “The case for synchronous concurrency” illustrates these differences in practical terms with an example.

The synchronous model of Céu is presented in more depth in these videos.
The videos also show organisms in action together with the SDL graphical library.

Conclusion

Céu organisms reconcile objects and threads in a single abstraction mechanism.

Classes specify the behavior of organisms, hiding implementation details and exposing an interface in which they can be manipulated by other organisms.

In the next post, I’ll show how Céu can control the life cycle of organisms with lexical scope in three different ways: local variables, named allocation, and anonymous allocation.

http://www.ceu-lang.org/

Written by francisco

May 22, 2013 at 6:59 pm

“Céu: Embedded, Safe, and Reactive Programming”

with one comment

We have published a technical report entitled “Céu: Embedded, Safe, and Reactive Programming”.

Enjoy the reading!

Abstract:

Céu is a programming language that unifies the features found in dataflow and imperative synchronous reactive languages, offering a high-level and safe alternative to event-driven and multithreaded systems for embedded systems.

Céu supports concurrent lines of execution that run in time steps and are allowed to share variables. However, the synchronous and static nature of Céu enables a compile time analysis that can enforce deterministic and memory-safe programs.

Céu also introduces first-class support for “wall-clock” time (i.e. time from the real world), and offers seamless integration with C and simulation of programs in the language itself.

The Céu compiler generates single-threaded code comparable to handcrafted C programs in terms of size and portability.

Table of Contents:

  1. Introduction
  2. The Language Céu
    1. Parallel compositions
    2. Internal events & Dataflow support
    3. Wall-clock time
    4. Integration with C
    5. Bounded execution
    6. Determinism
    7. Asynchronous execution
    8. Simulation in Céu
    9. GALS execution
  3. Demo applications
    1. WSN ring
    2. Arduino ship game
    3. SDL game simulation
  4. Implementation of Céu
    1. Temporal analysis
    2. Memory layout
    3. Gate allocation
    4. Code generation
    5. Reactive execution
    6. Evaluation
  5. Related work
    1. Synchronous model
    2. Asynchronous model
  6. Conclusion

A “down to earth” reactive language: Céu

leave a comment »

It has been more than one year since my last blog post. The reason is the direction I took two years ago, in the beginning of my PhD, switching from LuaGravity to something more grounded.

LuaGravity was very fun to work with, it showed how reactive languages are expressive, allowing complex dependency patterns to be written with simple expressions. It also showed how easily Lua can be hacked in runtime to provide a completely different semantics.

However, LuaGravity is overly powerful as a research artifact. In this context, what really matters is to understand the motivations, goals, and what is needed  and not needed in a reactive language. The border between Lua and LuaGravity was unclear and Lua is too dynamic, what complicates the deterministic execution enforcement we wanted to provide.

The development of a new language—Céu—is the process to answer and pose research questions related to reactive languages.

Céu can be defined in keywords as a reactive, imperative, concurrent, synchronous, and deterministic language. The syntax is very compact (resembling CSP or Pi-calculus), what is great for writing papers and discussing programs, but not necessarily for developing applications.

Currently, Céu is targeted at Wireless Sensor Networks, but any constrained embedded platform is of our interest. Follows a “Hello World!” program in Céu  that blinks three leds, each with a different frequency, forever:

(
    ( ~250ms  ; ~>Leds_led0Toggle)*
||
    ( ~500ms  ; ~>Leds_led1Toggle)*
||
    ( ~1000ms ; ~>Leds_led2Toggle)*
)

.

I presented Céu in the Doctoral Colloquium [1] at Sensys’11 last week. The 3-page summary submitted to the conference can be reached here.

[1] http://www.cse.ust.hk/~lingu/SenSys11DC/

Written by francisco

November 15, 2011 at 11:24 pm

SBLP – Full Paper available

leave a comment »

Click here to get the PDF with the full paper presented at SBLP entitled “LuaGravity: a Reactive Language based on Implicit Invocation”.

Written by francisco

August 27, 2009 at 5:07 pm

Paper accepted.

leave a comment »

Good news received last week:

Dear Mr. Francisco Sant’Anna,

I am pleased to confirm that your paper “LuaGravity, a Reactive Language
Based on Implicit Invocation” has been accepted for presentation and
publication at SBLP 2009.

All papers went through a rigorous reviewing process by the program
committee. Out of 30 research papers and 3 tutorials submitted, 12
papers and 1 tutorial were accepted.

Please make sure that in the preparation of the final paper you
carefully address the reviewers’ comments. Additionally, at least one
author is required to register in the conference for your paper to
appear in the proceedings.

Congratulations again on having your paper accepted. We look forward to
seeing you in Gramado!

Reviewer’s comments already addressed and final version submitted! One reviewer in particular pointed several constructive observations, which we took very seriously in the final version.

Follows the abstract for the paper:

The reactive programming paradigm covers a wide range of applications, such as
games and multimedia systems.
Mainstream languages do not offer proper support for reactive programming,
lacking language-level primitives that focus on synchronism and interactions
within application parts.
We propose an imperative reactive language, called
LuaGravity, based on
unconventional implicit invocation mechanisms.
LuaGravity allows dataflow programming, sequential imperative execution, and
deterministic use of shared-memory.
With this work, we intend to unite the essential features of reactive languages
while keeping a convenient imperative style of programming.

SBLP [1] is the main Brazilian congress on programming languages. This year it will be held in Gramado on August 18-21.

[1] http://sblp2009.ucpel.tche.br/

“A Synchronous Reactive Language based on Implicit Invocation”

leave a comment »

Observados os dispositivos do art. 6º da DELIBERAÇÃO 001/76, será defendida no dia 16/03/2009 às 10:00h, no local RDC511, a DISSERTAÇÃO DE MESTRADO intitulada “A Synchronous Reactive Language based on Implicit Invocation” do(a) aluno(a) Francisco Figueiredo Goytacaz Sant’Anna candidato ao título de Mestre em Informática.

Abstract:


The reactive programming paradigm covers a wide range of applications, such as games and multimedia systems.
Mainstream languages neglect reactive programming, lacking language-level primitives that focus on synchronism and interactions within application parts.


We propose a new reactive synchronous language, with an imperative style, whose primitives are based on unconventional implicit invocation mechanisms.
With this work, we intend to unite the essential features of reactive languages while keeping a convenient imperative style of programming.
A reactive scheduler is responsible for executing reactors, our processing units, based on dependency relations between them built dynamically.
Our language provides dataflow programming, sequential imperative execution, and deterministic use of shared-memory.

Written by francisco

March 9, 2009 at 10:13 pm

Reactivity in LuaGravity

with 3 comments

The reactivity in LuaGravity is achieved with implicit method invocation. So what?

Suppose we have the following class definition:

MyClass = class {
   function init (self, name)
       self._name = name
   end
   function ping (self)
       print('ping', self._name)
   end
   function pong (self)
       print('pong', self._name)
   end
}

That is, a simple class with a property name and two methods: ping and pong.

Now we create three objects and link some of their methods:

a = MyClass('a')
b = MyClass('b')
c = MyClass('c')

LINK(a.ping, b.pong)
LINK(b.pong, c.ping)
LINK(c.ping, a.pong)

Then, a simple call to a.ping yields in:

> a.ping()
ping    a
pong    b
ping    c
pong    a

That simple! A method is implicitly called in reaction to a call in another condition method.
Comparing to event-driven programming, there’s no need to define or post events, it’s all made implicitly. Much less verbosity.


The reactive variables of LuaGravity (shown here and here) override Lua’s default behavior for attribution.

So that

b = a
a = 2

Is equivalent to

LINK(a.update, b.update)
a.update(2)

Variables are, instead, special objects with an update method.

The parameter in a method call is propagated through its link chain as in a pipeline.
This way the value 2 is also passed to b.update.


A simple example of using LuaGravity in multimedia applications would go like this:

LINK(video1.start, video2.start)
LINK(video3.stop,  video4.start)

The first link makes video1 and video2 play in parallel, while the second link makes video3 and video4 play in sequence.

By overloading the operators + and * one could just write:

video1 + video2  -- play in parallel
video3 * video4  -- play in sequence

In LuaGravity, event definition is implicit, event posting is implicit and event linking may also be implicit (through operator overloading).

Given the amount of times the word implicit appears in this text, could LuaGravity be considered an implicit implicit invocation system?

Written by francisco

September 1, 2008 at 12:05 am