
\chapter{Motivation}
\label{chap:motivation}

In this chapter overall aim of the diploma thesis is described. A unique programming paradigm
is introduced together with the list of its possible and already existing applications \cite{programmingParadigms}.

\section{Semantic vs. paradigmatic restrictions in programming languages}

During last decades many programming languages emerged. Every such language has a syntax
which restricts possible statements expressible in the particular programming language.
Each of these statements has semantics which describes its \"real\" effect, e.g., changing
variable's value and printing something to the screen \cite{syntaxSemantics}.

Syntax and corresponding semantics are restricting programs that are expressible in the particular
programming language. For example, in most functional programming languages there is no \textit{syntactically}
correct statement which has \textit{semantics} of assigning a value to the global variable. Therefore, it is
\textbf{semantically} restricted that side-effects are not allowed in the program written in such functional
language. On the other hand, if side-effects free restriction is desired in an imperative programming language,
which has syntax and semantics for global variable assign, functional programming paradigm has to be correctly
used by the programmer. This restriction is \textbf{paradigmatic} and is very error-prone because programmer's
mistakes can lead to violating it.

A good thing about \textbf{paradigmatic restrictions} is that it is possible to use multiple different programming
paradigms in one general purpose language. However, because \textit{restrictions} are not semantically required,
a compiler or an interpreter often cannot perform optimizations that might be easily possible within
\textbf{semantically restricted} programming language.

This diploma thesis introduces programming paradigm and programming language which \textbf{semantically}
restricts programs to use this paradigm. The paradigm aims to allow automatic parallelization of the program execution.

\section{Message-driven programming paradigm}

Message-driven (i.e., event-driven) programs periodically receive messages (i.e., events) and adjust global
program state according to these messages. Schema of such program, in pseudocode, is following:
\begin{figure}[H]
  \begin{center}
    \begin{lstlisting}
      msg := NIL
      while msg != EXIT do
        msg := receiveMsg()
        processMsg(msg)
      end
    \end{lstlisting}
  \end{center}
  \caption{Schema of the message-driven program}
\end{figure}

According to the schema, the program is processing each received message. During this processing, the global
state of the program is adjusted. This schema is, however, sequential - processing of the message has to end
before next message can be processed. This may lead to the state in which messages are waiting even they might
be processed in parallel. However, the parallel execution could cause race conditions, because processing of two
messages can access the same global variable. Dealing with such parallel access is also often needed during
transactions handling of many database systems \cite{transactions}. It can be resolved in many ways, e.g.:
\begin{enumerate}
  \item Lock each global variable before accessing it and unlock it after access is not needed anymore.
  This is very simple to implement, but it does not guarantee that global state is consistent during whole
  message processing.

  \item Lock all needed global variables before starting processing message and unlock them after the message
  is processed. This solution guarantee that message processing sees the consistent global state. \textit{This is
  also a solution that will be discussed in this diploma thesis in more details.}
\end{enumerate}

For using the second solution, which allows parallel processing, scheme of the message-driven program can be altered:
\begin{figure}[H]
  \begin{center}
    \begin{lstlisting}
      msg := NIL
      while msg != EXIT do
        msg := receiveMsg()
        readVariables := getMsgReadVariables(msg)
        writeVariables := getMsgWriteVariables(msg)
        scheduleMsgProcessing(
          msg, readVariables, writeVariables
        )
      end
    \end{lstlisting}
  \end{center}
  \label{fig:parallel_schema}
  \caption{Schema of the parallel message-driven program}
\end{figure}

This schema incorporates the scheduler algorithm which can parallelize message processing based on
global program variables which are read and written by messages' processing.

Description of this scheduler algorithm is provided in the \hyperref[chap:scheduler]{\textit{Scheduler chapter}}.
An algorithm for analyzing program code and extracting a list of read and written variables is described in the
\hyperref[chap:compiler]{\textit{Interpreter chapter}}.

\section{Usage of the message-driven programming}

Message-driven programs have some \textit{semantic} or \textit{paradigmatic} restrictions that can make
creating of these programs harder for the programmers. Despite that, such programs are currently widely
used in the real-world applications of various kinds.

\subsection{Server-client applications}

This kind of applications is waiting for requests from various clients or users. When any of the
requests come, it is processed by the application. Processing can involve reading or even updating
the internal state of the application. These applications aim to be as fast as possible. Performance
can be improved by parallel processing of incoming requests, e.g., by using the schema introduced in
the sections above.

When creating a message-driven program for this kind of applications, each request can be viewed as
a message. For each of the messages a list of read and written variables is determined. This is all that
scheduler needs to properly parallelize the processing of the messages.

\subsection{Graphic user interface applications}

This kind of applications is typically used by one user that interacts with the application, e.g.,
by clicking on the controls that are rendered by the application. In addition to processing these user
events, messages that ask for application rendering or inform about new data availability can be received.
These applications aim to provide smooth user experience, for which rendering at a frame rate of 60 frames
per second is needed on current devices.

For this kind of applications, every user event can be viewed as a message for scheduling. Also, each render
request and the data message is a message for the scheduling algorithm. Render requests are in most cases
read-only, making the potential of parallelization even more significant.

\subsection{Node.js callback-based applications}

Node.js is a framework for creating scalable network programs using JavaScript language \cite{nodeJS}.
Applications written for this framework are fundamentally asynchronous. All standard input-output functions
in this framework take a callback as one of the arguments. This callback is called asynchronously by the
framework's runtime system to inform the program about input-output operation progress.

Despite these callbacks are called asynchronously, there are not executed in parallel. Reason for that
is an impossibility to determine which portion of the global state is used by the callback. It is impossible
due to a massively dynamic character of the JavaScript programming languages.

Using the scheduler and the static analyzer introduced in this diploma thesis it might be possible to create
a framework that is similar to the Node.js but also parallelize callbacks execution. This is possible because
calling the callback can be viewed as the message processing. This new framework will, however, have to use
a programming language that is not so dynamic as JavaScript is.
