Manage the mutual exclusion of agent attributes used in different "on" statements or in different behaviors

[ngaud]

Example

Agent a {
var t : Integer = 0

on toto {
do smthg with t
}
on tata {
do smthg with t
}

}

In this case, in the generated java code we must explicitly managed the mutual exclusion using synchonized or better with ReentrantLock.

[gallandarakhneorg]

Two points are coming in my mind concerning this issue:

• I did not see the difference between the semantic of the do with statement and the synchronize statement (already supported).
• Since we have a complete control on the generated code, I think it will be better for the SARL developer to hide the synchronization as much as possible in the SARL code.

The JVM inferrer may detect the use of the attributes in the behavior units (and the actions?) and implicitly add the synchronization statements (or make the attribute volatile) in the generated Java code.

[gallandarakhneorg]

This issue may have benefit of the automatic generation of the getter functions, Issue #582.

[gallandarakhneorg]

Before generating automatically the synchronization statements within Java, we should write a component that detects the potential synchronization problems within the validator.

[gallandarakhneorg]

See Issue #810 for the problem detection.

[ssardina]

This is one of the most tricky, difficult, painful issues. Of course it is not because of SARL, but because the great level of implicit parallelism that SARL supports and produces.

Manually adding all the locks is painful but ignoring the issue all together will produce systems that are not robust and that here and there will make huge mistakes!

This is in fact a topic of research: how to automatically find potential conflicts and add monitors/locks?

Although will not solve the locks among behaviors on, why SARL does not have synchronized on behaviors at least? Like synchronised on, the same way we can do synchronised def? Is there any reason?

[ssardina]

@gallandarakhneorg @ngaud , let me propose something that I bet you have thought already

what about adding a keyowrd sync to data definition, like:

sync var x : Map.... = new HashMap()

The idea is that the user says that x will need synchronization in a some places. Then the SARL compiler will generate behind a lock lock_x variable as usual.

Then, whenever the user wants the sync to be used, the user writes #x or something, denoting "the locked version of x" and so instead of x the compiler will translate to:

syncrhonized (lock_x) x

Though I am not sure the extend which SARL can do sync on expressions as explained here

For example, I have this code:

if (! kb_getPercepts(eisName)) // This is blocking!!

SARL complains about eisName. So I would like to write:

if (! kb_getPercepts(#eisName)) // This is blocking!!

which will be read as:

if (! kb_getPercepts(synchronized (eisName) {eisName})) // This is blocking!!

so one does not even create a lock data. Lots of cases will be resolved with this. Not all, but lots.

[ssardina]

BTW, looking at ECLIPSE I realize you have included a convenient template to generate sync expressions. which is kind of doing something in these lines..

[gallandarakhneorg]

@ssardina Thank you for your suggestions. As you have noticed, we already propose a synchronized statement; and we recommend to use tha auto-synchronized types (e.g. AtomicInteger, ConcurrentArrayList, etc.). It is now possible to have a robust SARL program; but with effort for synchronizing by hand. We have also the "volatile" keyword available (but we have disabled it until now) as in Java. The next step will be to hide the synchronization to the SARL developer.

[ssardina]

When you say "we already proposed a synchronized element", what do you mean? That comes from Java right? Do we have synchronized on already? I don't think so.

The synchronized statement is exactly the same as the one in Java (there is a direct transformation from SARL to Java).

But I really did not know about the auto-sync types and where exactly SARL recommends their use? That is really KEY and resolves a LOT of cases right away.

Take a look on the types Atomic* and into the package java.util.concurrent. They provide a lot of interesting types that could be directly used for supporting the synchronization.

I have no idea what voliteis, I just learnt about it. Maybe the doc should have a section about synchronization, why and the various ways available/recommended?

volatile comes from Java too. It has a close meaning as "synchronized field". Until now, the volatile modifier is supported only in object types, not in agent types, because we are still working on the synchronization problem.

[gallandarakhneorg]

Documentation must be improved for sure. If you have suggestion, you're welcome :-)

There is not search tool on the website. It is pure HTML without PHP. I don't know if it is possible to include a search engine only based on JavaScript. I will create a specific issue for this point.

[ssardina]

It is unfair that I criticize it because it's actually very good and neat!!

But as SARL is not a toy system, well there is indeed a lot of knowledge. Many times I know it is there in the doc, but justs cannot find it.

One way could be to just use Google. If I type in Google:

site:http://www.sarl.io/docs synchronization

it does work and get pages in doc where "synchronization" is meantioned.

can you just add that into the web? Not worth putting a lot more work on that, prefer you put the energy elsewhere!