Can you detail a little bit more the expected scenario. What I observe is
doSomething (TRUE)
blah (x)
doSomething(FALSE)
bal (x+1)

Actually, in some cases I see twice blah (x), which should be the expected behaviour

Further analysis indicates that the sporadic function is actually called twice, which is expected per the semantics I see in the AADL CV. After that, the code is in the VT generated GUI code. I'd like to annotate it for debug, is it safe to change it and re-run build-script ?

Sure, you can
You can also replace the GUI with a simple function in native language and use it to put annotation.

In addition, I changed the GUI implementation to a basic C code + instrumentation of PolyORB-HI/C.
Basically, blah now does this

void mygui_PI_blah(const asn1SccMyInteger IN_a)
{
/ Write your code here! */
printf ("blah: %d\n", *IN_a);
}

instead of using the mqueue implementation

I get this

taste@tastevm:~/tool-src/testSuites/Demo_Multi_Instances$ ./binary.c/binaries/x86_partition
[Generic_A] startup
[Generic_A] startup
2 0 0
1 0 0
3 0 0
4 0 1
blah: 0
4 0 0
blah: 0
3 0 0
1 0 0
2 0 0
4 0 1
blah: 1
4 0 0
blah: 1
3 0 0
1 0 0
2 0 0
4 0 1
blah: 2
4 0 0
blah: 2

I have this trace output up to blah:254 then it goes back to 0, which is the behaviour of function 2 and 3 AFAICT (being instances of generic_a.pr SDL)

OK, so you are saying that the message losses are most likely happening somewhere between the taste binary and the GUI itself (ie. in the mqueue handling) ?

My test with a C implementation instead of a GUI one seems to indicate the issue is in the queue management or further in the processing. I suggest you test with C as well to test and confront.

I also (quickly) read the code you generate. I see you are using a mutex to protect calls to the queue when communicating with the GUI. But I do not know what is done after, in particular when the message is actually sent. Since I started the GUI with some delay after the x86 partition, I'm kind of curious if we have some bad behaviour there.

Ok I will try to reproduce.
We are using a mutex to protect calls to the queue? I hope that's not part of the user code! Mutex should only be generated based on what is in the AADL models.

Thanks for your investigation, I will check it further (in the plane tonight!)

The mutex is part of the generated code

You do that in binary.c/mygui/mygui_polyorb_interface.c (generated AFAICT)

void sync_mygui_blah(void *a, size_t a_len)
{
extern process_package__taste_protected_object mygui_protected;
__po_hi_protected_lock (mygui_protected.protected_id);
mygui_blah(a, a_len);
__po_hi_protected_unlock (mygui_protected.protected_id);
}

and then ..

taste@tastevm:~/tool-src/testSuites/Demo_Multi_Instances$ grep -r mygui_protected *|grep -v aadl|grep -v matches
binary.c/GlueAndBuild/deploymentview_final/x86_partition/subprograms.c:extern process_package__taste_protected_object mygui_protected;
binary.c/GlueAndBuild/deploymentview_final/x86_partition/activity.c:extern process_package__taste_protected_object mygui_protected;
binary.c/GlueAndBuild/deploymentview_final/x86_partition/main.c:process_package__taste_protected_object mygui_protected;
binary.c/GlueAndBuild/deploymentview_final/x86_partition/main.c: mygui_protected.protected_id = 0;
binary.c/mygui/mygui_polyorb_interface.c: extern process_package__taste_protected_object mygui_protected;
binary.c/mygui/mygui_polyorb_interface.c: __po_hi_protected_lock (mygui_protected.protected_id);
binary.c/mygui/mygui_polyorb_interface.c: __po_hi_protected_unlock (mygui_protected.protected_id);
binary.c/mygui/mygui_polyorb_interface.c: extern process_package__taste_protected_object mygui_protected;
binary.c/mygui/mygui_polyorb_interface.c: __po_hi_protected_lock (mygui_protected.protected_id);
binary.c/mygui/mygui_polyorb_interface.c: __po_hi_protected_unlock (mygui_protected.protected_id);

so the mutex is declared in main.c (that I generate), and initialised also by main() through the __po_hi_protected_init () as part of the __po_hi_initialize_early () call

note that the mutex is not the issue: this mutex calls the message queue (blah PI)
but there is a need also for a mutex in the message queue API in case of concurrent calls, I missed it (very quick inspection during ERTSS talk this morning)

In this particular project there is only one gui, so it should not be the cause of the problem

However you are right, if there is mqueue API shared by all GUIs running on the same node, it should be protected. I will create a separate ticket for that.

Fixed in asn1_value_editor, the bug was in the Python GUI thread polling the message queue. If the same message was received twice, it could be discarded. (commit 2b37465f)