[e-lang] Properties of E scheduling

[Ka-Ping Yee]

Hi Matej.

At the risk of getting this wrong, i'll try replying to your message
based on what i know about E.  I hope Mark and others will correct me
if i'm mistaken.

On Wed, 6 Jul 2005, Matej Kosik wrote:
> Suppose that you have an information system which
> keeps track of the bank accounts registered in a bank. Suppose that
> there comes million request to make some operation. For the simplicity's
> sake lets assume that all those million clients want to reveal their
> balance. When information system in the bank works in asingle vat, than
> serving all the operations (milion turns of the same vat) would make the
> customers to wait a long time.

Can we compare this with an alternative system?  If you were to
build such a system in another programming language, i think you
would face the same challenges.  If the bank system runs on Unix,
for example, then running the bank in multiple concurrent processes
would not be any faster than running the bank in a single process.
You still have only one CPU.  In fact, using lots of processes
would be slower because of the extra context-switching overhead.

> E programmer thus has to break the
> theinformation system into finer and finer units (vats) in order to gain
> real parallelism (when those vats are running on different machines). I
> do not like the idea of managing the paralelism explicitely.

The only way you would make the bank respond faster would be to
split up the work among multiple computers.  And to do that, in
most programming systems, you would have to manage the parallelism
explicitly.  I think it is fair to say that E could be made more
powerful for solving these problems by adding tools for managing
this kind of parallelism, but I also haven't heard of other
languages that have this kind of support built in.  More importantly,
there isn't anything about E's basic design that prevents you from
building such support.

Is there a more convenient way of managing parallel work on multiple
machines that you have in mind?

> Now, assume that there are two concurrent activities (for example two
> different simulations). The first simulation at the end does this:
>
>      Transcript <- printLine("The first line of the FIRST report.");
>      Transcript <- printLine("The second line of the FIRST report.");
>      Transcript <- printLine("The third line of the FIRST report.");
>
> The second simulation similarly does this:
>
>      Transcript <- printLine("The first line of the SECOND report.");
>      Transcript <- printLine("The second line of the SECOND report.");
>      Transcript <- printLine("The third line of the SECOND report.");
>
> When they are performed at the same time, then according to the E's
> semantics the following text may appear in the Transcript
>
>      The first line of the FIRST report
>      The first line of the SECOND report.
>      The second line of the FIRST report.
>      The second line of the SECOND report.
>      The third line of the FIRST report.
>      The third line of the SECOND report.
>
> and that is bad because it does not have sense. That is not what you
> wanted when you programmed the particular simulation.

That is part of the intended meaning of the "<-" operator.  To write
three separate method calls in this way:

    Transcript <- printLine("The first line of the FIRST report.");
    Transcript <- printLine("The second line of the FIRST report.");
    Transcript <- printLine("The third line of the FIRST report.");

is to express that you want the three operations to happen separately.
If you want the entire report to be printed continuously, you could
simply write:

    Transcript <- printLine("The first line of the FIRST report.\n" +
                            "The second line of the FIRST report.\n" +
                            "The third line of the FIRST report.")

> The problem in E (and in concurrent environment) is that the references
> to remote objects are stateless. This causes problems when we deal with
> stateful objects in concurrent environment. For example
>
>      simulation1 <- runAndReportTo(Transcript)
>      simulation2 <- runAndReportTo(Transcript)
>      simulation3 <- runAndReportTo(Transcript)
>
> Is a problem because, reference to Transcript is (is normal systems)
> stateless (I do not know of any system where references are "stateful",
> i.e. part of some cleverly designed partial ordering together with
> mails). You again cannot besure about the order in which the particular
> reports will appear in the Transcript. They could be even intermixed.

Indeed, if you wrote the above, the reports could occur in any order
because the simulations could take different amounts of time to finish.

No matter what language you were using, in order to enforce the reports
to be printed in a particular order, you would either have to wait for
each one to finish before proceeding with the next one, or you would
have to collect the results before printing them.

To run each simulation separately, you could write this:

    when (simulation1 <- runAndReportTo(Transcript)) -> {
        when (simulation2 <- runAndReportTo(Transcript)) -> {
            simulation3 <- runAndReportTo(Transcript)
        }
    }

Or to run the simulations concurrently but collect the results in
order, you could write this:

    def r1 := simulation1 <- generateReport()
    def r2 := simulation2 <- generateReport()
    def r3 := simulation3 <- generateReport()
    when (r1, r2, r3) -> {
        Transcript <- printLine(r1 + r2 + r3)
    }

I hope this clears things up a bit.  Does that help?


-- ?!ng